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
