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:12:13 +0000 (UTC)
From: "John Rocha (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <JIRA.12624037.1355515906408.8787.1355515933410@arcas>
In-Reply-To: <JIRA.12624037.1355515906408@arcas>
References: <JIRA.12624037.1355515906408@arcas>
Subject: [jira] [Created] (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

John Rocha created AMQCPP-446:
---------------------------------

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


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