Thanks for pointing that out, Alex. As I was not able to compile and run a source version with the patch you mentioned applied, I´ll stay with this "solution". My application is not in production yet.
I am looking forward to see your patch (hopefully) in the next release of ActiveMQ. Thank you for your contributions. Alex Dean-2 wrote: > > > On Oct 8, 2010, at 5:09 AM, jule wrote: > >> >> I found a (quite obvious) solution to this problem. I just added a call >> to >> removeListener() of amq.js just before adding my listener on startup, >> like >> so: >> >> amq.removeListener(id, destination); >> amq.addListener(id, destination, callBack); >> >> Now it works perfectly fine for me. Maybe this should be included in the >> Getting Started document as that would have saved me quite a bit of time. > > I think you've still got a race condition to contend with. If both your > removeListener POST and your addListener POST return before the first > polling GET (triggered by amq.init()) times out, you'll end up with your > subscriptions (from addListener) in a different JSESSIONID than your > polls, and you'll never receive messages. > > The solution we've implemented is to do an initial poll with a very short > timeout. We don't send any addListener calls to the server until this > inital poll has returned, so they always end up in the same session. We > did this by allowing amq.init() to accept a configuration option called > sessionInitializedCallback. addListener calls go in this callback. > > We're just waiting on AMQ-2948 before submitting this patch. > > alex > > > -- View this message in context: http://activemq.2283324.n4.nabble.com/Beginner-problem-Too-many-consumers-on-queue-after-browser-restart-tp2719286p2969061.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
