[
https://issues.apache.org/jira/browse/APLO-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401188#comment-13401188
]
Lionel Cons commented on APLO-217:
----------------------------------
I find this confusing. In APLO-215 you suggest that adding a receipt to the
DISCONNECT frame (and waiting for the RECEIPT frame back) is enough to make
Apollo process the previously sent frames. For APLO-217, the same recipe does
not seem to guarantee anymore the processing of the previously sent frames. The
only difference is the type of frames sent before the DISCONNECT: ACK in
APLO-215 versus SEND in APLO-217.
I think it's worth discussing this on the stomp-spec list. I'll start a thread
on this matter.
> 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
