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

On 2/18/2011 8:29 AM, Florin Pop wrote:
> 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