Bugzilla – Bug 4107
notification deadlock
Last modified: 2006-01-24 12:49:21
You need to log in before you can comment on or make changes to this bug.
"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)
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.
Committed the fixes to globus_4_0_branch.
