activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lionel Cons (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (APLO-217) Broker does not always send all the messages to concurrent topic consumers
Date Mon, 25 Jun 2012 13:55:44 GMT

    [ https://issues.apache.org/jira/browse/APLO-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400485#comment-13400485
] 

Lionel Cons commented on APLO-217:
----------------------------------

In this simplified use case I can add a receipt to the last message (and I will try this soon)
but in real life use cases it is not always possible to know if a message being sent is the
last one or not. Sometimes you have to look for a new one to send to realize that there are
no more.

In any case, STOMP frames are received in order by the broker so isn't it enough to get a
RECEIPT for frame n+1 (here = DISCONNECT) to be sure that frame n (here = last SEND) has been
successfully processed by the broker? Imagine that the last SEND fails, shouldn't the broker
send an ERROR frame for that failed SEND before the RECEIPT for the DISCONNECT?
                
> 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

        

Mime
View raw message