]
Bela Ban commented on JGRP-620:
-------------------------------
The problem is that when we invoke RpcDispatcher.callRemoteMethods() on {A,B,C}, but C
left the cluster *before* the call, we wait forever on C.
This is 50% the error of the user who should *not* cache member lists, but pass
'null' instead of a vector, but sometimes passing an explicit vector is useful.
Solution: we have to weed out elements from the vector which are not in the current view
anymore.
RpcDispatcher.callRemoteMethods() hangs
---------------------------------------
Key: JGRP-620
URL:
http://jira.jboss.com/jira/browse/JGRP-620
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5.1
Environment: RHEL4 64 bit: Linux svr5 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16
17:13:42 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
SUN JDK 1.5.0_12-b04 64 bit
Reporter: P Eger
Assigned To: Bela Ban
Fix For: 2.5.2, 2.6.1, 2.7
Attachments: bla.java, stacktrace.txt, tcp-config.xml
RpcDispatcher.callRemoteMethods() hangs, while there is a lot of member churn at the time
(4 servers starting into a cluster of 4). 1 of the 4 server starting up is hung with the
attached stack trace.
-------------------------------------------------------------------
channel=new JChannel(jgroups_config_file);
channel.setOpt(Channel.AUTO_RECONNECT, Boolean.TRUE);
channel.addChannelListener(this);
//TODO: verify these startup params
//NOTE: deadlock detection leaks memory as of 2.5b2, do not use
disp=new RpcDispatcher(channel, null, this, this, false, true);
//force connect
channel.connect(clusterName);
MethodCall mc = new MethodCall("remoteBroadcastAvailability", new
Object[]{peer,sequence,serviceStatus,rotationStatus}, new
Class[]{Address.class,Long.class,ServiceStatus.class,RotationStatus.class});
disp.callRemoteMethods(channel.getView().getMembers(), mc, GroupRequest.GET_ALL, 0);
-------------------------------------------------------------------
Name: main
State: WAITING on java.util.HashMap@2d95bbec
Total blocked: 53 Total waited: 12
Stack trace:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:474)
org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:479)
org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:190)
org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:430)
org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:199)
org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:167)
org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:163)
utils.cluster.PeerClusterManager.broadcastAvailability(PeerClusterManager.java:1110)
utils.cluster.PeerClusterManager.broadcastMyAvailability(PeerClusterManager.java:428)
init.InitManager.ensureInitialized(InitManager.java:552)
init.InitManager.__init(InitManager.java:409)
init.InitManager.init(InitManager.java:300)
init.ServletListener.contextInitialized(ServletListener.java:23)
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3669)
org.apache.catalina.core.StandardContext.start(StandardContext.java:4104)
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
org.apache.catalina.core.StandardService.start(StandardService.java:450)
org.apache.catalina.core.StandardServer.start(StandardServer.java:683)
org.apache.catalina.startup.Catalina.start(Catalina.java:537)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271)
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: