[
https://issues.apache.org/jira/browse/AMQCPP-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538497#comment-13538497
]
John Rocha commented on AMQCPP-446:
-----------------------------------
Haven't had a chance to complete this. They changed focus on the test platform
so I couldn't run the test with your new 3.5 image. I won't be able to get on
this until after the new year.
> 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
