Bug 4107 - notification deadlock
: notification deadlock
Status: RESOLVED FIXED
: Java WS Core
globus_wsrf_core
: unspecified
: PC Windows XP
: P3 critical
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-12-13 22:27 by
Modified: 2006-01-24 12:49 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-12-13 22:27:22
"WorkThread-5427" daemon prio=1 tid=0x089342d0 nid=0x4340 in Object.wait() 
[b9dff000..b9dff8d0]
	at java.lang.Object.wait(Native Method)
	- waiting on <0x4a7ed548> (a org.globus.wsrf.container.Lock)
	at java.lang.Object.wait(Object.java:429)
	at EDU.oswego.cs.dl.util.concurrent.ReentrantLock.acquire(Unknown 
Source)
	- locked <0x4a7ed548> (a org.globus.wsrf.container.Lock)
	at org.globus.wsrf.impl.ResourceHomeImpl.find(ResourceHomeImpl.java:260)
	at org.globus.wsrf.impl.SimpleSubscriptionTopicListener.getSubscription
(SimpleSubscriptionTopicListener.java:140)
	at org.globus.wsrf.impl.SimpleSubscriptionTopicListener.topicChanged
(SimpleSubscriptionTopicListener.java:92)
	at org.globus.wsrf.impl.SimpleTopic.topicChanged(SimpleTopic.java:199)
	- locked <0x4a4b0e88> (a org.globus.wsrf.impl.SimpleTopic)
	at org.globus.wsrf.impl.SimpleTopic.notify(SimpleTopic.java:106)
	at org.globus.wsrf.impl.ResourcePropertyTopic.fireNotification
(ResourcePropertyTopic.java:208)
	at org.globus.wsrf.impl.ResourcePropertyTopic.set
(ResourcePropertyTopic.java:236)
	at org.globus.transfer.reliable.service.TransferWork.statusChanged
(TransferWork.java:188)
	- locked <0x4a772568> (a 
org.globus.transfer.reliable.service.TransferWork)
	at org.globus.transfer.reliable.service.TransferWork.processStates
(TransferWork.java:492)
	- locked <0x4a772568> (a 
org.globus.transfer.reliable.service.TransferWork)
	at org.globus.transfer.reliable.service.TransferWork.run
(TransferWork.java:725)
	at org.globus.wsrf.impl.work.WorkManagerImpl$WorkWrapper.run
(WorkManagerImpl.java:364)
	at java.lang.Thread.run(Thread.java:534)


"ServiceThread-5374" daemon prio=1 tid=0x6bd19d00 nid=0x420e waiting for 
monitor entry [b9ffe000..b9fff8d0]
	at org.globus.wsrf.impl.SimpleTopic.topicListenerIterator
(SimpleTopic.java:128)
	- waiting to lock <0x4a4b0e88> (a org.globus.wsrf.impl.SimpleTopic)
	at org.globus.wsrf.impl.ResourcePropertyTopic.topicListenerIterator
(ResourcePropertyTopic.java:172)
	at org.globus.wsrf.impl.notification.SimpleSubscription.removeListener
(SimpleSubscription.java:352)
	- locked <0x4a4b0ea8> (a org.globus.wsrf.impl.ResourcePropertyTopic)
	at org.globus.wsrf.impl.notification.SimpleSubscription.remove
(SimpleSubscription.java:332)
	- locked <0x4a4e66f0> (a 
org.globus.transfer.reliable.service.ReliableFileTransferResource)
	at org.globus.wsrf.impl.notification.PersistentSubscription.remove
(PersistentSubscription.java:217)
	- locked <0x4a4b0d90> (a 
org.globus.wsrf.impl.notification.PersistentSubscription)
	at org.globus.wsrf.impl.ResourceHomeImpl.remove
(ResourceHomeImpl.java:335)
	at org.globus.wsrf.impl.lifetime.DestroyProvider.destroy
(DestroyProvider.java:40)
	at sun.reflect.GeneratedMethodAccessor315.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
------- Comment #1 From 2005-12-14 23:09:40 -------
I committed a fix for this issues to trunk. I will also apply the fix to 
globus_4_0_branch once all tests check out ok.

The fix involves changing how key locks are obtained. There is a notion now of 
a remove lock vs. a regular lock. If a remove lock is obtained by some thread, 
and some other thread is trying to obtain a regular (or remove) lock for the 
same key at the same time, the acquire function will fail (it's a new acquire
(boolean) function, the old acquire() function will continue to work exactly as 
before) and NoSuchResourceException will be raised. 
------- Comment #2 From 2006-01-24 12:49:21 -------
Committed the fixes to globus_4_0_branch.