activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <>
Subject [jira] [Resolved] (AMQCPP-446) AMQ CPP Client locks in activemq::transport::inactivity::InactivityMonitor::stopMonitorThreads
Date Sat, 05 Jan 2013 19:18:13 GMT


Timothy Bish resolved AMQCPP-446.

       Resolution: Fixed
    Fix Version/s: 3.5.0

As far as I can tell this should not be an issue in the 3.5.0 code.  If you see this again
in the latest release, reopen and attach some backtrace info or better yet a test case. 
> AMQ CPP Client locks in activemq::transport::inactivity::InactivityMonitor::stopMonitorThreads
> ----------------------------------------------------------------------------------------------
>                 Key: AMQCPP-446
>                 URL:
>             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
>             Fix For: 3.5.0
>         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:

View raw message