Mailing-List: contact commits-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Fri, 22 Jun 2012 14:13:42 +0000 (UTC)
From: "Hiram Chirino (JIRA)" <jira@apache.org>
To: commits@activemq.apache.org
Message-ID: <709491165.44023.1340374422640.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <703955945.32823.1338789143818.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Resolved] (APLO-210) Sending persistent message to a
 durable subscription would eventually lockup producers.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/APLO-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hiram Chirino resolved APLO-210.
--------------------------------

    Resolution: Fixed

Bug fix committed.  I've deployed build apache-apollo-99-trunk-20120622.140958-54 with the fix.
                
> Sending persistent message to a durable subscription would eventually lockup producers.
> ---------------------------------------------------------------------------------------
>
>                 Key: APLO-210
>                 URL: https://issues.apache.org/jira/browse/APLO-210
>             Project: ActiveMQ Apollo
>          Issue Type: Bug
>          Components: apollo-broker
>         Environment: apollo-99-trunk-20120519.032132-42
>            Reporter: Lionel Cons
>            Assignee: Hiram Chirino
>            Priority: Blocker
>             Fix For: 1.4
>
>         Attachments: apollo.dump, apollo2.dump
>
>
> One of our applications using Apollo seems to trigger a very severe bug inside the broker.
> The application is very simple: a few short lived producers that send a few messages to a single topic, disconnect and start again after some time, plus one or two long lived consumers using durable subscriptions. All this works fine initially but after some time (15 to 30 minutes, it depends), this stops working and the sent messages are not received anymore.
> On the surface, the broker seems to be working fine and other clients do work. However, the console reports weird statistics for the topic: the enqueued and dispatched counters do grow while dequeued does not change. Worse: the broker is in a bizarre state and cannot be stopped cleanly ("service apollo stop" yields to "Could not stop process PID") and only "kill -9" can get rid of it.
> I've tried to reproduce the problem with simple scripts and I could not. I suspect a concurrency problem between the concurrent producers and consumers.
> I will attach a stack dump of the broker when it is in this weird state. If this is not enough, we can give you access to the broker the next time this happens.

--
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