[jgroups-dev] Hang at org/javagroups/JChannel.connect(JChannel.java:257)

Hi gurus,

I have a legacy application deployed in a cluster and in certain cases 
when a node in the cluster fails it is not able to rejoin the cluster.
It seems to be hanged with a stack like this:

"[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default 
(self-tuning)'" id=14 idx=0x40 tid=21992 prio=5  alive, in native, 
waiting, daemon
-- Waiting for notification on: java/lang/Object@0x2aaabb4dd010[fat lock]
at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native 
Method)
at java/lang/Object.wait(J)V(Native Method)
at java/lang/Object.wait(Object.java:485)
at org/javagroups/JChannel.connect(JChannel.java:257)
^-- Lock released while waiting: java/lang/Object@0x2aaabb4dd010[fat lock]
^-- Holding lock: org/javagroups/JChannel@0x2aaabb4d60f8[biased lock]
at org/javagroups/blocks/NotificationBus.start(NotificationBus.java:116)
at 
com/opensymphony/oscache/plugins/clustersupport/JavaGroupsBroadcastingListener.initialize(JavaGroupsBroadcastingListener.java:96)
^-- Holding lock: 
com/opensymphony/oscache/plugins/clustersupport/JavaGroupsBroadcastingListener@0x2aaabb4cf3f8[biased 
lock]
at 
com/opensymphony/oscache/base/AbstractCacheAdministrator.configureStandardListeners(AbstractCacheAdministrator.java:299)
at 
com/opensymphony/oscache/general/GeneralCacheAdministrator.createCache(GeneralCacheAdministrator.java:297)
at 
com/opensymphony/oscache/general/GeneralCacheAdministrator.<init>(GeneralCacheAdministrator.java:99)

The application is using an acient Javagroups version:
fpop@logan:~$ java -cp javagroups-all.jar org.javagroups.Version

Version:        2.1.0
CVS:            $Id: Version.java,v 1.21 2003/06/30 16:53:05 belaban Exp $
History:        (see doc/history.txt for details)

Was wondering if this a known issue for this version and if this was 
addressed in the newer releases. Otherwise if you can suggest how can I 
determine the cause of this hang. In all cases bouncing the whole 
cluster is the ultimate solution and it works every time without any 
changes in the multicast addresses / network configuration.

Thanks in advance,
Florin P®P
Bucharest, Romania

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

_______________________________________________
Javagroups-development mailing list