Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MPD listeners not registered when mpd is not running while starting #14

Open
avdv opened this issue Jan 19, 2014 · 8 comments
Open

MPD listeners not registered when mpd is not running while starting #14

avdv opened this issue Jan 19, 2014 · 8 comments
Assignees
Labels

Comments

@avdv
Copy link

avdv commented Jan 19, 2014

Because of how the initialization is done, the various listeners will never be registered when an exception is thrown at https://github.com/msteiger/play-mpc/blob/master/app/controllers/Application.java#L74

@ghost ghost assigned msteiger Jan 20, 2014
@msteiger
Copy link
Owner

That's right. You cannot use the instance if an exception is thrown in the constructor. Which exception do you get and what' the point in continuing if initialization doesn't work?

@avdv
Copy link
Author

avdv commented Jan 20, 2014

Which exception do you get

I'm getting a MPDConnectionException

and what' the point in continuing if initialization doesn't work?

Counter-question: Why do you make the initialization fail if the connection cannot be established at startup?

Ideally, the app would try to connect to an MPD instance continuously, and register the listeners once a connection is established. Repeat after the connection is lost.

[To my (biased) mind this would be a perfect fit for using Akka with play2. But, currently, I'm still withstanding the reflex to re-implement the app myself...]

@msteiger
Copy link
Owner

I see now, what you mean. Would it make sense to plug Akka into the existing Java application? I'm a fan of baby steps - gradual transformation over complete restart.

@avdv
Copy link
Author

avdv commented Jan 23, 2014

Honestly, I have no experience with using Akka in Java. I have played a bit with some ideas which lead me to nowhere during the hour of spare time I spent on this (mainly because the interfaces of Java and Scala for Akka as well as for play differ quite a bit).

I tried to separate the Websocket handling into an actor (because there're concurrency issues with the current implementation - I got ConcurrentModificationException's ). Seems in play 2.2 - when using Scala - there's a broadcast Websocket mechanism available which would solve this without much ado.

Babysteps are nice, but sometimes hard to do. I have to think a bit more about this perhaps.

[in the meantime, I have added a display of the currently playing song to the playlist page. Alas, it's still a bit rough around the edges and needs some polishing]

@avdv
Copy link
Author

avdv commented Jan 24, 2014

update: after another fiddling last evening, I successfully re-implemented the Websocket handling in Scala using the aforementioned Concurrent.broadcast mechanism. This should solve the concurrency problems and makes the code very concise. I just began learning play, but I'm starting to love it...

I'll keep you informed and upload the patches when I find the time.

@msteiger
Copy link
Owner

Awesome - looking to forward to seeing that!

@avdv
Copy link
Author

avdv commented Jan 26, 2014

I just pushed my code into this branch: https://github.com/avdv/play-mpc/tree/scala-app

Works pretty well.

But there's a glitch. (almost) Every time a "reload" command is send over the websocket, a ClosedChannelException is thrown - it doesn't break the app, but it's not pretty either.

Since the code is quite similar to the original Chat sample of the play framework, I've asked on their mailing list what the problem could be. Now I'm waiting for an answer -- or some bright idea...

@msteiger
Copy link
Owner

Nice - will look into that asap, probably Thursday.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants