[
https://issues.apache.org/jira/browse/QPID-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526148
]
Rafael H. Schloming commented on QPID-572:
------------------------------------------
That's what I did. With those steps it occurs consistently for me when running
TransactedTest. Were you testing on the trunk or M2? If M2 then you could try
the same steps on the trunk where the bug is known to exist. If it doesn't
occur for you on the trunk then we know that it is a timing issue related to
our different environments.
It's possible that your extra cores are making the problem harder to reproduce
since your consumer will be running on its own core. Reproducing the problem
requires there to be messages backed up in the queue in order for the async
delivery thread to be able to kick in. If your consuming thread has its own
core, that may never happen. It may be that we need to rate limit the consumer
in order to get the same effect on your machine. You could try putting an
additional Thread.sleep() in dispatchMessage inside AMQSession.
> broker delivers messages out of order
> -------------------------------------
>
> Key: QPID-572
> URL: https://issues.apache.org/jira/browse/QPID-572
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1, M3
> Reporter: Rafael H. Schloming
>
> ConcurrentSelectorDeliveryManager will sometimes deliver messages out of
> order. This is caused by the code in deliver(...) that attempts to
> short-circuit message queuing when there is an available subscription. This
> code can result in the currently published message skipping ahead of queued
> messages causing out of order delivery. Although unrelated to transactions, I
> have observed this failure occuring in TransactedTest both in testCommit and
> testRollback. Normally it does not happen very frequently, however placing a
> Thread.sleep(500) in the async delivery thread will cause the failure to
> occur almost all the time.
> I tried fixing the problem by only attempting synchronous delivery when there
> are no queued messages, however this appears to break other tests that use
> selectors. This makes me suspect that the selector implementation is somehow
> incorrectly coupled to synchronous delivery.
> I have only verfied this issue on the trunk, however I believe it effects M2
> as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
