[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] [Commented] (AMQCPP-446) AMQ CPP Client locks in activemq::transport::inactivity::InactivityM
From:       "Timothy Bish (JIRA)" <jira () apache ! org>
Date:       2012-12-21 23:05:12
Message-ID: JIRA.12624037.1355515906408.45229.1356131112821 () arcas
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/AMQCPP-446?page=com.atlassian.jira.plugin. \
system.issuetabpanels:comment-tabpanel&focusedCommentId=13538513#comment-13538513 ] 

Timothy Bish commented on AMQCPP-446:
-------------------------------------

Official v3.5.0 release bundle is here: 
http://activemq.apache.org/cms/activemq-cpp-350-release.html
                
> 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


[prev in list] [next in list] [prev in thread] [next in thread]