6:01 a.m.
disconnect() hangs forever on second client of group
----------------------------------------------------
Key: JGRP-392
URL: http://jira.jboss.com/jira/browse/JGRP-392
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
"UDP(mcast_addr=239.10.10.10;mcast_port=17000" +
";ip_ttl=8;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
Reporter: ?yvind Eikeland
Assigned To: Bela Ban
Quite often, but not every time, when member 2 (not the coordinator) is disconnecting from
the group, it will wait forever. This may be some configuration or network issue, but it
would be very useful if a timeout could be specified in the JChannel.disconnect() method
to get around this problem. Members are running in separate JVMs.
when a member/client is leaving a channel, we're calling these methods:
- channel.disconnect();
- channel.close();
This method is called from disconnect() today:
disconnect_promise.getResult(); // wait for DISCONNECT_OK
Instead, disconnect_promise.getResult(timeout); should be called. It does not seem to be
possible to configure this timeout in the protocol stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:16 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-392) disconnect() hangs forever on second client of group
[ http://jira.jboss.com/jira/browse/JGRP-392?page=all ]
Bela Ban updated JGRP-392:
--------------------------
Fix Version/s: 2.5
disconnect() hangs forever on second client of group
----------------------------------------------------
Key: JGRP-392
URL: http://jira.jboss.com/jira/browse/JGRP-392
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
"UDP(mcast_addr=239.10.10.10;mcast_port=17000" +
";ip_ttl=8;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
Reporter: ?yvind Eikeland
Assigned To: Bela Ban
Fix For: 2.5
Quite often, but not every time, when member 2 (not the coordinator) is disconnecting
from the group, it will wait forever. This may be some configuration or network issue, but
it would be very useful if a timeout could be specified in the JChannel.disconnect()
method to get around this problem. Members are running in separate JVMs.
when a member/client is leaving a channel, we're calling these methods:
- channel.disconnect();
- channel.close();
This method is called from disconnect() today:
disconnect_promise.getResult(); // wait for DISCONNECT_OK
Instead, disconnect_promise.getResult(timeout); should be called. It does not seem to be
possible to configure this timeout in the protocol stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:16 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-392) disconnect() hangs forever on second client of group
[ http://jira.jboss.com/jira/browse/JGRP-392?page=comments#action_12349037 ]
Bela Ban commented on JGRP-392:
-------------------------------
I need a stack trace of both servers when this happens
disconnect() hangs forever on second client of group
----------------------------------------------------
Key: JGRP-392
URL: http://jira.jboss.com/jira/browse/JGRP-392
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
"UDP(mcast_addr=239.10.10.10;mcast_port=17000" +
";ip_ttl=8;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
Reporter: ?yvind Eikeland
Assigned To: Bela Ban
Fix For: 2.5
Quite often, but not every time, when member 2 (not the coordinator) is disconnecting
from the group, it will wait forever. This may be some configuration or network issue, but
it would be very useful if a timeout could be specified in the JChannel.disconnect()
method to get around this problem. Members are running in separate JVMs.
when a member/client is leaving a channel, we're calling these methods:
- channel.disconnect();
- channel.close();
This method is called from disconnect() today:
disconnect_promise.getResult(); // wait for DISCONNECT_OK
Instead, disconnect_promise.getResult(timeout); should be called. It does not seem to be
possible to configure this timeout in the protocol stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:31 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-392) disconnect() hangs forever on second client of group
[ http://jira.jboss.com/jira/browse/JGRP-392?page=comments#action_12349039 ]
?yvind Eikeland commented on JGRP-392:
--------------------------------------
Stacktrace from member two, which hangs (produce by pressing Ctrl-Break in console). This
is all I captured in the console. Let me know if you need more.
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d0b0> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (GMS)" daemon prio=6 tid=0x034f5c00 nid=0xaa0 in Object.wait()
[0x0
3dcf000..0x03dcfa94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d158> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d158> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (STABLE)" daemon prio=6 tid=0x034f5400 nid=0x228 in Object.wait()
[0x
03d7f000..0x03d7fb94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d200> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d200> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (STABLE)" daemon prio=6 tid=0x03527000 nid=0x1314 in Object.wait()
[0x03d2f000..0x03d2fb14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d2a8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d2a8> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (UNICAST)" daemon prio=6 tid=0x03525c00 nid=0x13a4 in Object.wait()
[
0x03cdf000..0x03cdfc14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d350> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d350> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (UNICAST)" daemon prio=6 tid=0x034fe800 nid=0xf2c in Object.wait()
[0x03c8f000..0x03c8fc94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d3f8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d3f8> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (NAKACK)" daemon prio=6 tid=0x034fd800 nid=0xcc in Object.wait()
[0x0
3c3f000..0x03c3fd14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d4a0> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d4a0> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (NAKACK)" daemon prio=6 tid=0x0352b000 nid=0x17b4 in Object.wait()
[0x03bef000..0x03befd94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d548> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d548> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (VERIFY_SUSPECT)" daemon prio=6 tid=0x0352a000 nid=0x168c in
Object.w
ait() [0x03b9f000..0x03b9fa14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d5f0> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d5f0> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (VERIFY_SUSPECT)" daemon prio=6 tid=0x034fbc00 nid=0x1770 in
Object
.wait() [0x03b4f000..0x03b4fa94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d698> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d698> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (FD_SOCK)" daemon prio=6 tid=0x034fb400 nid=0x1488 in Object.wait()
[
0x03aff000..0x03affb14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d740> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d740> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (FD_SOCK)" daemon prio=6 tid=0x034d0800 nid=0x1420 in
Object.wait()
[0x03aaf000..0x03aafb94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d7e8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d7e8> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (PING)" daemon prio=6 tid=0x034cf400 nid=0x1730 in Object.wait()
[0x0
3a5f000..0x03a5fc14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d890> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d890> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (PING)" daemon prio=6 tid=0x034fa400 nid=0x17f8 in Object.wait()
[0
x03a0f000..0x03a0fc94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0928d938> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0928d938> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"DownHandler (UDP)" daemon prio=6 tid=0x03500400 nid=0x1490 in Object.wait()
[0x
039bf000..0x039bfd14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0927ea70> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0927ea70> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"Start Level Event Dispatcher" daemon prio=6 tid=0x03177400 nid=0x12e8 in
Object
.wait() [0x0386f000..0x0386fc14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0919e800> (a org.eclipse.osgi.framework.eventmgr.EventMa
nager$EventThread)
at java.lang.Object.wait(Object.java:485)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextE
vent(EventManager.java:349)
- locked <0x0919e800> (a org.eclipse.osgi.framework.eventmgr.EventManage
r$EventThread)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(Even
tManager.java:287)
"Framework Event Dispatcher" daemon prio=6 tid=0x03153400 nid=0x1500 in
Object.w
ait() [0x0381f000..0x0381fc94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0919e878> (a org.eclipse.osgi.framework.eventmgr.EventMa
nager$EventThread)
at java.lang.Object.wait(Object.java:485)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextE
vent(EventManager.java:349)
- locked <0x0919e878> (a org.eclipse.osgi.framework.eventmgr.EventManage
r$EventThread)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(Even
tManager.java:287)
"RMI TCP Accept-20000" daemon prio=6 tid=0x03076c00 nid=0x164c runnable
[0x0336f
000..0x0336fd94]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x09184b18> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTr
ansport.java:369)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:3
41)
at java.lang.Thread.run(Thread.java:619)
"RMI TCP Accept-0" daemon prio=6 tid=0x03074800 nid=0x1b4 runnable
[0x0331f000..
0x0331fa14]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x09184d10> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTr
ansport.java:369)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:3
41)
at java.lang.Thread.run(Thread.java:619)
"Low Memory Detector" daemon prio=6 tid=0x02c7d400 nid=0x31c runnable
[0x0000000
0..0x00000000]
java.lang.Thread.State: RUNNABLE
"CompilerThread0" daemon prio=10 tid=0x02c78800 nid=0x1654 waiting on condition
[0x00000000..0x02f2f798]
java.lang.Thread.State: RUNNABLE
"Attach Listener" daemon prio=10 tid=0x02c77400 nid=0xbb4 runnable
[0x00000000..
0x00000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=10 tid=0x02c76400 nid=0x554 waiting on
condition
[0x00000000..0x00000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=8 tid=0x02c71c00 nid=0x15fc in Object.wait()
[0x02e3f000
..0x02e3fc94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0916aa20> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0x0916aa20> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x02c6d800 nid=0x14b0 in Object.wait()
[0
x02def000..0x02defd14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0916aab0> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x0916aab0> (a java.lang.ref.Reference$Lock)
"main" prio=6 tid=0x002e6400 nid=0xeac in Object.wait()
[0x0092f000..0x0092fe5c]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x09253cb0> (a org.jgroups.util.Promise)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Promise.doWait(Promise.java:100)
at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:52)
at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:28)
- locked <0x09253cb0> (a org.jgroups.util.Promise)
at org.jgroups.util.Promise.getResult(Promise.java:77)
at org.jgroups.JChannel.disconnect(JChannel.java:473)
- locked <0x0924b170> (a org.jgroups.JChannel)
at no.fast.esp.coreservices.clustering.plugins.jgroups.JGroupsUtils.clos
e(JGroupsUtils.java:163)
at no.fast.esp.coreservices.clustering.plugins.jgroups.JGroupsClustering
Provider.teardown(JGroupsClusteringProvider.java:214)
- locked <0x0924b258> (a java.lang.Object)
at no.fast.esp.coreservices.clustering.plugins.jgroups.JGroupsClustering
Provider.releaseResources(JGroupsClusteringProvider.java:231)
at no.fast.esp.coreservices.clustering.clusteringimpl.ClusteringServiceI
mpl.stop(ClusteringServiceImpl.java:187)
- locked <0x09238828> (a java.lang.Object)
at no.fast.esp.coreservices.nodemanager.AbstractComponent.managedStop(Ab
stractComponent.java:368)
at no.fast.esp.coreservices.nodemanager.NodeController.shutdownComponent
(NodeController.java:996)
at no.fast.esp.coreservices.nodemanager.NodeController.removeCriticalCor
eComponents(NodeController.java:971)
at no.fast.esp.coreservices.nodemanager.NodeController.shutdown(NodeCont
roller.java:170)
at no.fast.esp.coreservices.nodemanager.NodeRunner.stopNode(NodeRunner.j
ava:157)
at no.fast.esp.coreservices.nodemanager.NodeRunner.run(NodeRunner.java:1
82)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja
va:376)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja
va:163)
at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.j
ava:136)
"VM Thread" prio=10 tid=0x02c64400 nid=0x15bc runnable
"VM Periodic Task Thread" prio=10 tid=0x0307d400 nid=0x1248 waiting on
condition
JNI global references: 659
Heap
def new generation total 3328K, used 2257K [0x069d0000, 0x06d60000, 0x0913000
0)
eden space 3008K, 64% used [0x069d0000, 0x06bb4760, 0x06cc0000)
from space 320K, 100% used [0x06d10000, 0x06d60000, 0x06d60000)
to space 320K, 0% used [0x06cc0000, 0x06cc0000, 0x06d10000)
tenured generation total 42932K, used 37905K [0x09130000, 0x0bb1d000, 0x269d0
000)
the space 42932K, 88% used [0x09130000, 0x0b6347f8, 0x0b634800, 0x0bb1d000)
compacting perm gen total 12288K, used 11245K [0x269d0000, 0x275d0000, 0x2a9d0
000)
the space 12288K, 91% used [0x269d0000, 0x274cb4c0, 0x274cb600, 0x275d0000)
ro space 8192K, 66% used [0x2a9d0000, 0x2af19920, 0x2af19a00, 0x2b1d0000)
rw space 12288K, 52% used [0x2b1d0000, 0x2b816130, 0x2b816200, 0x2bdd0000)
=============================================
stacktrace from the coordinator, which is not hanging:
"UpHandler (UNICAST)" daemon prio=6 tid=0x03502c00 nid=0x1124 in Object.wait()
[
0x03ccf000..0x03ccfb14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab168> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab168> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (UNICAST)" daemon prio=6 tid=0x03501c00 nid=0x12d8 in
Object.wait()
[0x03c7f000..0x03c7fc94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab210> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab210> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (NAKACK)" daemon prio=6 tid=0x0351c400 nid=0xad8 in Object.wait()
[0x
03c2f000..0x03c2fd14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab2b8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab2b8> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (NAKACK)" daemon prio=6 tid=0x0351b400 nid=0x16b0 in Object.wait()
[0x03bdf000..0x03bdfd94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab360> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab360> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (VERIFY_SUSPECT)" daemon prio=6 tid=0x0351a400 nid=0x950 in
Object.wa
it() [0x03b8f000..0x03b8fa14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab408> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab408> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (VERIFY_SUSPECT)" daemon prio=6 tid=0x03518000 nid=0x1374 in
Object
.wait() [0x03b3f000..0x03b3fa94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab4b0> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab4b0> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (FD_SOCK)" daemon prio=6 tid=0x03517000 nid=0x878 in Object.wait()
[0
x03aef000..0x03aefb14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab558> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab558> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (FD_SOCK)" daemon prio=6 tid=0x03516400 nid=0x13ac in
Object.wait()
[0x03a9f000..0x03a9fb94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab600> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab600> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"UpHandler (PING)" daemon prio=6 tid=0x034e4c00 nid=0xb7c in Object.wait()
[0x03
a4f000..0x03a4fc14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab6a8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab6a8> (a java.lang.Object)
at org.jgroups.stack.UpHandler.run(Protocol.java:49)
"DownHandler (PING)" daemon prio=6 tid=0x0351e800 nid=0x1510 in Object.wait()
[0
x039ff000..0x039ffc94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x092ab750> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x092ab750> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"DownHandler (UDP)" daemon prio=6 tid=0x034fa400 nid=0x1350 in Object.wait()
[0x
039af000..0x039afd14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0926cbc8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jgroups.util.Queue.remove(Queue.java:263)
- locked <0x0926cbc8> (a java.lang.Object)
at org.jgroups.stack.DownHandler.run(Protocol.java:104)
"SystemManager ping thread" prio=6 tid=0x034cd400 nid=0x10e8 in Object.wait()
[0
x0395f000..0x0395fa14]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x091f3c30> (a java.lang.Object)
at no.fast.esp.utils.concurrent.ThreadAborter.waitOrAbort(ThreadAborter.
java:61)
at no.fast.esp.utils.concurrent.Worker.sleep(Worker.java:290)
- locked <0x091f3c30> (a java.lang.Object)
at no.fast.esp.coreservices.systemmanager.SystemPinger.doWorkIteration(S
ystemPinger.java:43)
at no.fast.esp.utils.concurrent.Worker.run(Worker.java:339)
at java.lang.Thread.run(Thread.java:619)
"Thread-1" daemon prio=6 tid=0x03490800 nid=0x738 in Object.wait()
[0x0390f000..
0x0390fa94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x09203e38> (a java.util.concurrent.LinkedBlockingQueue)
at java.lang.Object.wait(Object.java:485)
at no.fast.esp.coreservices.log.ArchiveFileHandler$Archiver.run(ArchiveF
ileHandler.java:313)
- locked <0x09203e38> (a java.util.concurrent.LinkedBlockingQueue)
at java.lang.Thread.run(Thread.java:619)
"ConfigurationUpdater: ConfigurationManager : RESOLVING" daemon prio=6
tid=0x034
95400 nid=0x17a8 runnable [0x038bf000..0x038bfb14]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x091f30f8> (a java.util.concurrent.locks.Abstra
ctQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198
)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject
.awaitNanos(AbstractQueuedSynchronizer.java:1927)
at java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:
342)
at no.fast.esp.coreservices.config.configman.ConfigurationManagerImpl.po
llForNextPid(ConfigurationManagerImpl.java:78)
at no.fast.esp.coreservices.config.configman.ConfigurationManagerImpl.po
llForNextPid(ConfigurationManagerImpl.java:83)
at no.fast.esp.coreservices.config.configman.ConfigurationUpdater.doWork
Iteration(ConfigurationUpdater.java:62)
at no.fast.esp.utils.concurrent.Worker.run(Worker.java:339)
at java.lang.Thread.run(Thread.java:619)
"Start Level Event Dispatcher" daemon prio=6 tid=0x030fd400 nid=0x200 in
Object.
wait() [0x0386f000..0x0386fc14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0919e720> (a org.eclipse.osgi.framework.eventmgr.EventMa
nager$EventThread)
at java.lang.Object.wait(Object.java:485)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextE
vent(EventManager.java:349)
- locked <0x0919e720> (a org.eclipse.osgi.framework.eventmgr.EventManage
r$EventThread)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(Even
tManager.java:287)
"Framework Event Dispatcher" daemon prio=6 tid=0x03224800 nid=0x1334 in
Object.w
ait() [0x0381f000..0x0381fc94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0919e798> (a org.eclipse.osgi.framework.eventmgr.EventMa
nager$EventThread)
at java.lang.Object.wait(Object.java:485)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextE
vent(EventManager.java:349)
- locked <0x0919e798> (a org.eclipse.osgi.framework.eventmgr.EventManage
r$EventThread)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(Even
tManager.java:287)
"RMI TCP Accept-17000" daemon prio=6 tid=0x0307c400 nid=0x1598 runnable
[0x0336f
000..0x0336fd94]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x091845d8> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTr
ansport.java:369)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:3
41)
at java.lang.Thread.run(Thread.java:619)
"RMI TCP Accept-0" daemon prio=6 tid=0x02d4fc00 nid=0xd48 runnable
[0x0331f000..
0x0331fa14]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x091847d0> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTr
ansport.java:369)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:3
41)
at java.lang.Thread.run(Thread.java:619)
"Low Memory Detector" daemon prio=6 tid=0x02c7d400 nid=0x1070 runnable
[0x000000
00..0x00000000]
java.lang.Thread.State: RUNNABLE
"CompilerThread0" daemon prio=10 tid=0x02c78800 nid=0x7ec waiting on condition
[
0x00000000..0x02f2f798]
java.lang.Thread.State: RUNNABLE
"Attach Listener" daemon prio=10 tid=0x02c77400 nid=0x1524 runnable
[0x00000000.
.0x02edfb40]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=10 tid=0x02c76400 nid=0x14a8 waiting on
conditio
n [0x00000000..0x00000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=8 tid=0x02c71c00 nid=0x17d8 in Object.wait()
[0x02e3f000
..0x02e3fc94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0916a728> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0x0916a728> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x02c6d800 nid=0x113c in Object.wait()
[0
x02def000..0x02defd14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0916a7b8> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x0916a7b8> (a java.lang.ref.Reference$Lock)
"main" prio=6 tid=0x002e6400 nid=0x958 runnable [0x0092f000..0x0092fe5c]
java.lang.Thread.State: RUNNABLE
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregi
sterMBean(DefaultMBeanServerInterceptor.java:433)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean
(DefaultMBeanServerInterceptor.java:403)
at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer
.java:506)
at no.fast.esp.utils.jmx.MonitoringUtils.unregisterMBean(MonitoringUtils
.java:69)
at no.fast.esp.coreservices.nodemanager.NodeRunner.unregisterAsMBean(Nod
eRunner.java:282)
at no.fast.esp.coreservices.nodemanager.NodeRunner.run(NodeRunner.java:1
81)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja
va:376)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja
va:163)
at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.j
ava:136)
"VM Thread" prio=10 tid=0x02c64400 nid=0x1208 runnable
"VM Periodic Task Thread" prio=10 tid=0x0307dc00 nid=0x808 waiting on condition
JNI global references: 900
Heap
def new generation total 960K, used 323K [0x069d0000, 0x06ad0000, 0x09130000)
eden space 896K, 34% used [0x069d0000, 0x06a1e008, 0x06ab0000)
from space 64K, 17% used [0x06ab0000, 0x06ab2e00, 0x06ac0000)
to space 64K, 0% used [0x06ac0000, 0x06ac0000, 0x06ad0000)
tenured generation total 7092K, used 5783K [0x09130000, 0x0981d000, 0x269d000
0)
the space 7092K, 81% used [0x09130000, 0x096d5c50, 0x096d5e00, 0x0981d000)
compacting perm gen total 12288K, used 7599K [0x269d0000, 0x275d0000, 0x2a9d00
00)
the space 12288K, 61% used [0x269d0000, 0x2713bc90, 0x2713be00, 0x275d0000)
ro space 8192K, 66% used [0x2a9d0000, 0x2af19920, 0x2af19a00, 0x2b1d0000)
rw space 12288K, 52% used [0x2b1d0000, 0x2b816130, 0x2b816200, 0x2bdd0000)
Shutting down node systemManager ...
Services in use:
no.fast.esp.coreservices.nodemanager.Component [28] used by bundle no.fast.e
sp.coreservices.remoting
Exiting...
Terminate batch job (Y/N)?
disconnect() hangs forever on second client of group
----------------------------------------------------
Key: JGRP-392
URL: http://jira.jboss.com/jira/browse/JGRP-392
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
"UDP(mcast_addr=239.10.10.10;mcast_port=17000" +
";ip_ttl=8;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
Reporter: ?yvind Eikeland
Assigned To: Bela Ban
Fix For: 2.5
Quite often, but not every time, when member 2 (not the coordinator) is disconnecting
from the group, it will wait forever. This may be some configuration or network issue, but
it would be very useful if a timeout could be specified in the JChannel.disconnect()
method to get around this problem. Members are running in separate JVMs.
when a member/client is leaving a channel, we're calling these methods:
- channel.disconnect();
- channel.close();
This method is called from disconnect() today:
disconnect_promise.getResult(); // wait for DISCONNECT_OK
Instead, disconnect_promise.getResult(timeout); should be called. It does not seem to be
possible to configure this timeout in the protocol stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:16 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-392) disconnect() hangs forever on second client of group
[ http://jira.jboss.com/jira/browse/JGRP-392?page=comments#action_12349047 ]
Bela Ban commented on JGRP-392:
-------------------------------
Okay, this should be discussed on the mailing lists first...
- If you can reproduce this, enable logging for org.jgroups at the TRACE level
- What's your config ? Make sure you have both FD *and* FD_SOCK
disconnect() hangs forever on second client of group
----------------------------------------------------
Key: JGRP-392
URL: http://jira.jboss.com/jira/browse/JGRP-392
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
"UDP(mcast_addr=239.10.10.10;mcast_port=17000" +
";ip_ttl=8;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
Reporter: ?yvind Eikeland
Assigned To: Bela Ban
Fix For: 2.5
Quite often, but not every time, when member 2 (not the coordinator) is disconnecting
from the group, it will wait forever. This may be some configuration or network issue, but
it would be very useful if a timeout could be specified in the JChannel.disconnect()
method to get around this problem. Members are running in separate JVMs.
when a member/client is leaving a channel, we're calling these methods:
- channel.disconnect();
- channel.close();
This method is called from disconnect() today:
disconnect_promise.getResult(); // wait for DISCONNECT_OK
Instead, disconnect_promise.getResult(timeout); should be called. It does not seem to be
possible to configure this timeout in the protocol stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:31 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-392) disconnect() hangs forever on second client of group
[ http://jira.jboss.com/jira/browse/JGRP-392?page=comments#action_12349053 ]
r p commented on JGRP-392:
--------------------------
I've see this behaviour as well. channel.disconnect() hangs. This appeared after I
switched from a TCP protocol to a TCP_NIO protocol.
I've tried with both <FD /> and <FD /> + <FD_SOCK /> stack.
Here is the config:
<TCP_NIO
recv_buf_size="20000000"
send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="true"
down_thread="false"
up_thread="false"
enable_bundling="true"
start_port="7800"
use_send_queues="false"
sock_conn_timeout="300"
skip_suspected_members="false"
reader_threads="8"
writer_threads="8"
processor_threads="8"
processor_minThreads="8"
processor_maxThreads="8"
processor_queueSize="100"
processor_keepAliveTime="-1"/>
<MPING
timeout="2000"
num_initial_members="2"
mcast_addr="229.6.7.8"
down_thread="false"
up_thread="false"/>
<pbcast.NAKACK
max_xmit_size="60000"
use_mcast_xmit="false"
gc_lag="10"
retransmit_timeout="100,200,300,600,1200,2400,4800"
down_thread="false"
up_thread="false"
discard_delivered_msgs="true" />
<pbcast.STABLE
stability_delay="1000"
desired_avg_gossip="50000"
down_thread="false"
up_thread="false"
max_bytes="400000"/>
<pbcast.GMS
print_local_addr="true"
join_timeout="3000"
down_thread="false"
up_thread="false"
join_retry_timeout="2000"
shun="true"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD
timeout="10000"
max_tries="5"
down_thread="false"
up_thread="false"
shun="true"/>
<MERGE2
min_interval="500"
max_interval="1000"
down_thread="false"
up_thread="false" />
<VERIFY_SUSPECT
timeout="1500"
down_thread="false"
up_thread="false"/>
<pbcast.STREAMING_STATE_TRANSFER
down_thread="false"
up_thread="false"
use_flush="true"
use_reading_thread="true"/>
<pbcast.FLUSH
down_thread="false"
up_thread="false"/>
disconnect() hangs forever on second client of group
----------------------------------------------------
Key: JGRP-392
URL: http://jira.jboss.com/jira/browse/JGRP-392
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
"UDP(mcast_addr=239.10.10.10;mcast_port=17000" +
";ip_ttl=8;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
Reporter: ?yvind Eikeland
Assigned To: Bela Ban
Fix For: 2.5
Quite often, but not every time, when member 2 (not the coordinator) is disconnecting
from the group, it will wait forever. This may be some configuration or network issue, but
it would be very useful if a timeout could be specified in the JChannel.disconnect()
method to get around this problem. Members are running in separate JVMs.
when a member/client is leaving a channel, we're calling these methods:
- channel.disconnect();
- channel.close();
This method is called from disconnect() today:
disconnect_promise.getResult(); // wait for DISCONNECT_OK
Instead, disconnect_promise.getResult(timeout); should be called. It does not seem to be
possible to configure this timeout in the protocol stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:33 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-392) disconnect() hangs forever on second client of group
[ http://jira.jboss.com/jira/browse/JGRP-392?page=comments#action_12349054 ]
r p commented on JGRP-392:
--------------------------
Other info:
JDK 1.5.06
Windows XP
disconnect() hangs forever on second client of group
----------------------------------------------------
Key: JGRP-392
URL: http://jira.jboss.com/jira/browse/JGRP-392
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
"UDP(mcast_addr=239.10.10.10;mcast_port=17000" +
";ip_ttl=8;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
Reporter: ?yvind Eikeland
Assigned To: Bela Ban
Fix For: 2.5
Quite often, but not every time, when member 2 (not the coordinator) is disconnecting
from the group, it will wait forever. This may be some configuration or network issue, but
it would be very useful if a timeout could be specified in the JChannel.disconnect()
method to get around this problem. Members are running in separate JVMs.
when a member/client is leaving a channel, we're calling these methods:
- channel.disconnect();
- channel.close();
This method is called from disconnect() today:
disconnect_promise.getResult(); // wait for DISCONNECT_OK
Instead, disconnect_promise.getResult(timeout); should be called. It does not seem to be
possible to configure this timeout in the protocol stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:41 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-392) disconnect() hangs forever on second client of group
[ http://jira.jboss.com/jira/browse/JGRP-392?page=all ]
Oyvind Eikeland updated JGRP-392:
---------------------------------
Attachment: coordinator.log
member.log
attaching the coordinator log and member log. member hangs on shutdown in our application.
Both FD and FD_SOCK is in the protocol stack
disconnect() hangs forever on second client of group
----------------------------------------------------
Key: JGRP-392
URL: http://jira.jboss.com/jira/browse/JGRP-392
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
"UDP(mcast_addr=239.10.10.10;mcast_port=17000" +
";ip_ttl=8;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
Reporter: Oyvind Eikeland
Assigned To: Bela Ban
Fix For: 2.5
Attachments: coordinator.log, member.log
Quite often, but not every time, when member 2 (not the coordinator) is disconnecting
from the group, it will wait forever. This may be some configuration or network issue, but
it would be very useful if a timeout could be specified in the JChannel.disconnect()
method to get around this problem. Members are running in separate JVMs.
when a member/client is leaving a channel, we're calling these methods:
- channel.disconnect();
- channel.close();
This method is called from disconnect() today:
disconnect_promise.getResult(); // wait for DISCONNECT_OK
Instead, disconnect_promise.getResult(timeout); should be called. It does not seem to be
possible to configure this timeout in the protocol stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:16 a.m.
New subject: [JBoss JIRA] Closed: (JGRP-392) disconnect() hangs forever on second client of group
[ http://jira.jboss.com/jira/browse/JGRP-392?page=all ]
Oyvind Eikeland closed JGRP-392.
--------------------------------
Resolution: Done
I have not been able to reproduce this issue in a while. Will reopen if it occurs again.
disconnect() hangs forever on second client of group
----------------------------------------------------
Key: JGRP-392
URL: http://jira.jboss.com/jira/browse/JGRP-392
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
"UDP(mcast_addr=239.10.10.10;mcast_port=17000" +
";ip_ttl=8;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
Reporter: Oyvind Eikeland
Assigned To: Bela Ban
Fix For: 2.5
Attachments: coordinator.log, member.log
Quite often, but not every time, when member 2 (not the coordinator) is disconnecting
from the group, it will wait forever. This may be some configuration or network issue, but
it would be very useful if a timeout could be specified in the JChannel.disconnect()
method to get around this problem. Members are running in separate JVMs.
when a member/client is leaving a channel, we're calling these methods:
- channel.disconnect();
- channel.close();
This method is called from disconnect() today:
disconnect_promise.getResult(); // wait for DISCONNECT_OK
Instead, disconnect_promise.getResult(timeout); should be called. It does not seem to be
possible to configure this timeout in the protocol stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7093
days inactive
7162
days old
8 comments
5 participants
participants (5)
-
?yvind Eikeland (JIRA) -
Bela Ban (JIRA)
-
Oyvind Eikeland (JIRA) -
Oyvind Eikeland (JIRA)
-
r p (JIRA)