Could Timothy Bish or someone else provide details on issue AMQCPP-376? We are running in to this issue on our production system. Is there a good way to work around this while keeping the Failover transport?
"The underlying deadlock issue is still there in trunk, so even though you didn't see it that time, it could still occur if timing changes at all." https://issues.apache.org/jira/browse/AMQCPP-376 In digging through the code I see a CMS thread is stuck on the join as shown below because the IOTransport input stream is blocked reading from the Socket. However, the comment below indicates the inputStream should be closed (closing the socket). Why isn't this occurring? // We have to close the input stream before // we stop the thread. this will force us to // wake up the thread if it's stuck in a read // (which is likely). Otherwise, the join that // follows will block forever. if( inputStream != NULL ){ inputStream->close(); inputStream = NULL; } // Wait for the thread to die. if( thread != NULL ){ thread->join(); thread.reset( NULL ); } -- View this message in context: http://activemq.2283324.n4.nabble.com/CMS-3-4-0-Deadlock-in-IOTransport-With-Failover-tp4092829p4092829.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
