Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Fri, 14 Dec 2012 20:14:12 +0000 (UTC)
From: "John Rocha (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <JIRA.12624037.1355515906408.8789.1355516052740@arcas>
In-Reply-To: <JIRA.12624037.1355515906408@arcas>
References: <JIRA.12624037.1355515906408@arcas>
Subject: [jira] [Updated] (AMQCPP-446) AMQ CPP Client locks in
 activemq::transport::inactivity::InactivityMonitor::stopMonitorThreads
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

John Rocha updated AMQCPP-446:
------------------------------

    Attachment: delme_amq_stack

{{delme_amq_stack}} is a GDB session attached to the application once it has locked up, and dumping where all the threads are.
                
> AMQ CPP Client locks in activemq::transport::inactivity::InactivityMonitor::stopMonitorThreads
> ----------------------------------------------------------------------------------------------
>
>                 Key: AMQCPP-446
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-446
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 3.4.5
>         Environment: RedHat Linux 5.8, SuSE Linux SLES10
>            Reporter: John Rocha
>            Assignee: Timothy Bish
>         Attachments: delme_amq_stack
>
>
> AMQ CPP Client locks in activemq::transport::inactivity::InactivityMonitor::stopMonitorThreads
> I have a scenario where the AMQ CPP Client (v3.4.5) locks up in
> stopMonitorThreads(), and it somehow seems to be related to the system load.
> We have a product that run on a Linux platform (RH or SUSE) and records video
> streams. The low level server code is written in C++ and it has a web interface
> written in Java and Javascript. We use AMQ to communicate between the two, all
> running on the same server.
> What I've found is it all works well when we have 250 streams and a total disk
> I/O of 74Mbps. However, if we increase to 250 streams with 185Mbps then it
> works fine for about 1 hour and 20 minutes. After that something happens to the
> broker and the CPP code has to reconnect. When it tries to reconnect we get
> this lockup.
> I've determined it's an indefinate lock up because the thread has been locked
> for more than 24 hours. I used GDB to attach and I was able to view the state
> of all the threads. I'm including a sanitized GDB dump.
> We are not using failover when we connect to the broker. We have an
> infrastructure that stores a boost shared pointer to the connection and checks
> that the connection is valid before each attempt. If ok then it setups up
> everything to send a message and does so.
> If there's a problem then it drops the shared pointer, which triggers the
> cms:Connection destructor and tries to establish a new connection to the
> broker.
> From the stack dump it appears that it is locking up during the Connection's
> destructor. I've also noticed that there appear to be other AMQ related threads
> running (also in the stack dump) although I don't know what they're doing
> (yet).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira