Mailing-List: contact commits-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Tue, 26 Jun 2012 11:33:43 +0000 (UTC)
From: "Hiram Chirino (JIRA)" <jira@apache.org>
To: commits@activemq.apache.org
Message-ID: <848248646.56007.1340710423676.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <60106899.50546.1340621382511.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (APLO-217) Broker does not always send all the
 messages to concurrent topic consumers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Hiram Chirino commented on APLO-217:
------------------------------------

Hi Lionel,

So waiting for the receipt on disconnect should be enough to assure the broker has received the message.  I'm not really sure the disconnect was actually waiting for a receipt from the disconnect to come back before closing the socket.  But that being said, it's important to note that waiting for the receipt on the disconnect is not enough to assure the the broker has persisted the message (in case of persistent messaging).

I'll add some some more test cases to verify this is actually the behavior.
                
> 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