[
https://issues.apache.org/jira/browse/APLO-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403013#comment-13403013
]
Lionel Cons commented on APLO-217:
----------------------------------
After further debugging, APLO-217.pl does indeed show a problem... but not in
Apollo.
The problem is on the client side with an incompatibility between select() to
test data availability and SSL's internal buffering. I've added a workaround to
Net::STOMP::Client (version >= 1.6_2, now in CPAN) and the test now passes with
Apollo.
Thanks for your help debugging this.
> Broker does not always send all the messages to concurrent topic consumers
> --------------------------------------------------------------------------
>
> Key: APLO-217
> URL: https://issues.apache.org/jira/browse/APLO-217
> Project: ActiveMQ Apollo
> Issue Type: Bug
> Environment: apollo-99-trunk-20120623.032010-57
> Reporter: Lionel Cons
> Attachments: APLO-217.pl
>
>
> I am seeing problems with concurrent consumers on a topic which are quite
> similar to APLO-215. In this case however, adding a receipt header on
> DISCONNECT does not make the problem go away.
> Here is the use case:
> - Nc concurrent consumers on a topic (one per thread) that consume until
> they stop receiving new messages
> - Np concurrent producers sending Nm messages to the topic (one per thread)
> Each consumer should receive Np * Nm messages but, in practice, some seem to
> receive less. Extra care is taken to make sure things happen in order. For
> instance, producers start sending only after all consumers have received a
> RECEIPT back confirming the subscription. See the attached script for more
> information.
> The results vary from one run to another. For instance, with Nc=Np=3 and
> Nm=10000:
> [2] drained 30000 messages
> [3] drained 30000 messages
> [1] drained 30000 messages
> (so this one is ok)
> [2] drained 29983 messages
> [3] drained 29983 messages
> [1] drained 29998 messages
> [1] drained 30000 messages
> [3] drained 30000 messages
> [2] drained 29980 messages
> [3] drained 29998 messages
> [1] drained 30000 messages
> [2] drained 29976 messages
> [2] drained 30000 messages
> [1] drained 29980 messages
> [3] drained 30000 messages
> You may have to try with other values to reproduce the problem more reliably.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira