Martin, comments/answers inline/
On Wed, Feb 18, 2009 at 8:33 AM, Martin Ritchie <[email protected]> wrote: > Rajith, > Do you have a test case that shows the dispatcher not starting on the > setting of a message listener after connection start? I don't have a test as part of the automated test suite. I wrote up a test case for testing some other issue and this popoed up. If need be I could create a JIRA and attach a patch. > The reason we don't automatically start is that if we create a > consumer on a session and never consume on it then starting the > dispatcher will fill the prefetch on that consumer. Agreed, I also think that if no listeners are present then it's a nice optimization to not start that extra thread. > This is something that Mule does so we ensure that all sessions are > started flowed and only unflow when a consumer actually attempts to > consume via consume() or setMessageListener(). > > While this may mean a delay in receiving the first message it ensures > that Mule users actually get all the messages on a queue. > > With the 0-10 code path I note that it attempts to reject all > messages in the _synchronousQueue, but it does this after calling > super.setMessageListener() which delivers all the messages in > _synchronousQueue. Yes this logic seems to be flawed. > Why does the 0-10 path attempt to reject messages? I did notice this and I also have no explanation as to why they are rejected. It used to be that MessageListener was using window mode and sync receive was using credit mode. But now that logic has changed based on the prefetch count. If count==0 then it uses credit mode and if count> 0, it uses window mode. I suspect the above logic was a leftover from the previous method of handling credit. I have marked this area and a few other odd areas for more close inspection. > Is there a case where the dispatcher may sneak an extra message in to > the _synchronusQueue after the first delivery purge in > AMQSession.setMessageListener()? > > If so then this would affect 0-8 and should be addressed at a different level. It's worthwhile investigating this. > > Cheers > > Martin > > 2009/2/18 Aidan Skinner <[email protected]>: >> On Tue, Feb 17, 2009 at 10:43 PM, Rajith Attapattu <[email protected]> >> wrote: >> >>> I noticed in the current codebase, >>> that when the connection is started, the dispatcher thread for a >>> particular session will not be started if there are no registered >>> message listeners. >>> But if I add a message listener later, the dispatcher thread should be >>> started, but apparently it does not seem to be. >> >> That seems odd, and implies that onMessage won't work. I would expect >> DispatcherTest.testAsynchronousRecieve to fail, amongst others in that >> case but they pass for me (running all three profiles). How are you >> testing this? >> >> - Aidan >> -- >> Apache Qpid - World Domination through Advanced Message Queueing >> http://qpid.apache.org >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> > > > > -- > Martin Ritchie > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
