On 17/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > Martin Ritchie wrote: > > Rafi. do you have a test case that can reproduce the problem in 602? > > I've been trying to do so by populating the queue and then connect a > > client wils sending more messages. So far it always gets the messages > > in the right order. I haven't had much time to get a failing test so i > > can test my solution so he you have such a test that would really > > help. > > I assume you mean QPID-601, not QPID-602.
Indeed I did, I don't have Qpid running on my phone as Robert suggested so had to remember the JIRA number > I had thought the TopicSessionTest failure was an example of the race > condition, however your explanation in another post also accounts for > that failure. Indeed, I haven't seen TST fail since I put that fix in, but I do see the window you are talking about. > I haven't tested this myself, but in theory a long enough Thread.sleep > at the end of ConcurrentSelectorDeliveryManager.populatePreDeliveryQueue > should make the race condition easy to reproduce because at that point > the Subscription has not been added to _subscriptions, so any messages > delivered at that point will be stranded in the _messages queue. Ah, I think I had to much of my fix in place. I was hoping to see re-ordering though as I was doing the add to the SubscriberSet before the populate. I'd really like a test case that fails, for the right reasons, without adding sleeps to the broker. I had hopped a large back log of complex selects to check might slow it down enough to let some new msgs slip through. Will take another look at it. I certainly have an approach that doesn't break things and only requires the _lock for a brief time. So shouldn't impact performance to much. I'd like to get the test sorted and commit it to M2.1 for you to cast your eye over it. Seems easier to commit it rather than have you apply at as a patch, but can do either That is unless Rob catches me doing work ;) > --Rafael -- Martin Ritchie
