[jboss-jira] [JBoss JIRA] Commented: (JGRP-527) MuxChannel stuck
Vladimir Blagojevic (JIRA)
jira-events at lists.jboss.org
Fri Jun 15 14:43:11 EDT 2007
[ http://jira.jboss.com/jira/browse/JGRP-527?page=comments#action_12365628 ]
Vladimir Blagojevic commented on JGRP-527:
------------------------------------------
Bryce,
Thanks a lot for the test code. Good news: I was able to reproduce issue locally. However, it was very hard for me to follow the application logic of all these multiplexers. I then proceeded to modify all your handlers to make sure that they are not doing anything in their respective receive methods. Thus I isolated application logic from JGroups. After I have done this change I was not able to reproduce this issue any more. This leads me to believe that there is something in application logic that locks up the channel thread. Would you please give it another look and so will I.
> MuxChannel stuck
> ----------------
>
> Key: JGRP-527
> URL: http://jira.jboss.com/jira/browse/JGRP-527
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Fix For: 2.5
>
> Attachments: dist.tar.gz
>
>
> [from Bryce Alcock]
> JGroups Users:
> I am getting what appears to me on the surface to be a dead lock.
> Here is the stack trace:
> "***************BLA-STUCK THREAD**********************" prio=1 tid=0x08448ed8 nid=0x78dc in Object.wait() [0xb0c10000..0
> xb0c110b0]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x88f500c8> (a org.jgroups.util.Promise)
> at org.jgroups.util.Promise.doWait(Promise.java:104)
> at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:60)
> at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:28)
> - locked <0x88f500c8> (a org.jgroups.util.Promise)
> at org.jgroups.mux.Multiplexer.fetchServiceInformation(Multiplexer.java:196)
> at org.jgroups.JChannelFactory.connect(JChannelFactory.java:355)
> - locked <0x88f37fe0> (a org.jgroups.JChannelFactory$Entry)
> at org.jgroups.mux.MuxChannel.connect(MuxChannel.java:126)
> - locked <0x88f63740> (a org.jgroups.mux.MuxChannel)
> at scheduledtaskexecuteframework.group.GenericMultiplexer.connect(GenericMultiplexer.java:83)
> at scheduledtaskexecuteframework.schedule.test.MainTest$1.run(MainTest.java:60)
> i?
> The Senarios is easily reproduced in my system:
> I have 2 members of a MuxChannel join and do some work.
> I then have a 3rd join.
> then I have the second member quit.
> wait about 5 mins and have the second member join.
> the second member will get stuck like this.
> However,
> If I dont have the 3rd member join, and just have the second member leave wait five mins and come back
> things work fine every time.
> here is the line of code that is both holding the mutex and asking for it (apperently in different threads)
> byte[] state=(byte[])service_state_promise.getResultWithTimeout(2000);
> I am more then willing to give more details about the situation, however,
> I am looking for Ideas on how to debug this.
> I am using java 1.5.0_11
> I am using JGroups-2.4.1-sp3
> Bryce
--
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
More information about the jboss-jira
mailing list