From commits-return-19126-apmail-activemq-commits-archive=activemq.apache.org@activemq.apache.org Tue Jun 26 05:49:47 2012 Return-Path: X-Original-To: apmail-activemq-commits-archive@www.apache.org Delivered-To: apmail-activemq-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5146C9897 for ; Tue, 26 Jun 2012 05:49:47 +0000 (UTC) Received: (qmail 23822 invoked by uid 500); 26 Jun 2012 05:49:47 -0000 Delivered-To: apmail-activemq-commits-archive@activemq.apache.org Received: (qmail 23721 invoked by uid 500); 26 Jun 2012 05:49:45 -0000 Mailing-List: contact commits-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list commits@activemq.apache.org Received: (qmail 23699 invoked by uid 99); 26 Jun 2012 05:49:45 -0000 Received: from issues-vm.apache.org (HELO issues-vm) (140.211.11.160) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jun 2012 05:49:45 +0000 Received: from isssues-vm.apache.org (localhost [127.0.0.1]) by issues-vm (Postfix) with ESMTP id 1FAF01418F1 for ; Tue, 26 Jun 2012 05:49:44 +0000 (UTC) Date: Tue, 26 Jun 2012 05:49:44 +0000 (UTC) From: "Lionel Cons (JIRA)" To: commits@activemq.apache.org Message-ID: <524461001.55152.1340689784131.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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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