Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1304325

Summary: Dead lock between Topology updates and connection creation
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: mstyk
Component: HornetQAssignee: jboss-set
Status: CLOSED WONTFIX QA Contact: Miroslav Novak <mnovak>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.4.0CC: csuconic, msvehla
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-01 12:28:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
log produced by org.hornetq.tests.integration.jms.cluster.MultipleThreadsOpeningTest.testMultipleOpen none

Description mstyk 2016-02-03 10:21:54 UTC 
Created attachment 1120714 [details]
log produced by org.hornetq.tests.integration.jms.cluster.MultipleThreadsOpeningTest.testMultipleOpen

Description of problem:

In a rare case deadlock between topology updates and connection creation may occur. This issue was fixed for ActiveMQ Artemis, but not for HornetQ. Complete information and description of this issue can be found here https://issues.apache.org/jira/browse/ARTEMIS-217
Attaching log of test org.hornetq.tests.integration.jms.cluster.MultipleThreadsOpeningTest.testMultipleOpen where this issue can be hit.
Comment 1 Miroslav Novak 2016-02-03 10:28:34 UTC 
Fix in ARTEMIS-217 caused another issue described in: https://issues.jboss.org/browse/JBEAP-1713

Fix from ARTEMIS-217 should be adjusted not to block update of "receivedTopology" attribute.
Comment 2 Clebert Suconic 2016-02-03 14:55:01 UTC 
not really, (unless there's another lock in place, causing a deadlock)... which I don't see indications here.


this is using wait/notify pattern, which means the lock will be released while the wait is in place.
Comment 3 Clebert Suconic 2016-02-03 16:24:05 UTC 
I meant to say.. I don't think the issue is caused by the change on ARTEMIS-217. If there's an issue it's something else.

I can't replicate it BTW?
Comment 4 Clebert Suconic 2016-02-04 02:02:27 UTC 
I got confused, thought this was a new request.. fixing it as part of JBEAP-1713
Comment 5 Clebert Suconic 2016-02-04 02:25:21 UTC 
I fixed JBEAP-1713 but I don't see any relation to this previously fixed issue on ARTEMIS-217. 

I've sent a fix as part of JBEAP-1713: https://github.com/apache/activemq-artemis/pull/369 which will be back ported into the JBoss EAP 7 branch
Comment 6 Miroslav Novak 2016-02-04 07:40:24 UTC 
ARTEMIS-217 added a synchronized block which delayed/blocked update of receivedTopology attribute in createSessionFactory() method and throw exception. I did not have time to study it deeply so it could be something else as well.
Comment 7 Miroslav Novak 2016-02-04 07:43:54 UTC 
MultipleThreadsOpeningTest.testMultipleOpen was failing on Artemis bacause of JBEAP-1713. 
As we did not see fix ARTEMIS-217 to be backported to HornetQ and saw that MultipleThreadsOpeningTest.testMultipleOpen test fails sometimes due to client not finished. It indicated that dead lock might be there similar to ARTEMIS-217 could be still in HornetQ.
Comment 8 JBoss JIRA Server 2016-02-08 09:13:36 UTC 
Erich Duda <eduda> updated the status of jira JBEAP-1713 to Resolved
Comment 9 JBoss JIRA Server 2016-06-14 11:37:48 UTC 
Jiri Pallich <jpallich> updated the status of jira JBEAP-1713 to Closed