[ http://jira.jboss.com/jira/browse/JBMESSAGING-660?page=comments#action_12... ] Ovidiu Feodorov commented on JBMESSAGING-660: --------------------------------------------- The race condition occurs while running ConcurrentCloseStressTest (thanks, Clebert). The root cause seems to be the fact that ChannelSupport.deliveryInternal() main while loop doesn't synchronize access to messageRefs strongly enough, so cancellations that arrive to the channel while looping may break the consistency and cause the chanel deliver the same message again and again. Trace snapshot attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-660?page=all ] Ovidiu Feodorov updated JBMESSAGING-660: ---------------------------------------- Fix Version/s: 1.0.1.SP2 (was: 1.0.1.GA) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-660?page=comments#action_12... ] Clebert Suconic commented on JBMESSAGING-660: --------------------------------------------- When I run the test I get an eventual dead lock. I have attached a trace... The object lock from ChannelSupport and the object lock from ServerConsumerEndpoint are bouncing with each other. Look at trace.txt (attached) for more details. "Thread-42" prio=1 tid=0x08269c00 nid=0x2a49 waiting for monitor entry [0x695d6000..0x695d71b0] at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:223) - waiting to lock <0xafb81b30> (a java.lang.Object) at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:110) at org.jboss.messaging.core.ChannelSupport.push(ChannelSupport.java:1652) at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:703) - locked <0x7175c310> (a java.lang.Object) at org.jboss.messaging.core.ChannelSupport$DeliveryRunnable.run(ChannelSupport.java:1695) at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-660?page=comments#action_12... ] Tim Fox commented on JBMESSAGING-660: ------------------------------------- I have fixed this by executing the cancel on the queue's event queue. This means we do not get a knock on deadlock and don't need to copy any deliveries in the server consumer endpoint. I have also strengthened checking and handling of ack/cancels/commits when session is closed - as this was giving a separate problem. I have also implemented jdbc deadlock retry on all db updates rather than just one which we were previously doing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-660?page=all ] Ovidiu Feodorov closed JBMESSAGING-660. --------------------------------------- Resolution: Done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira