[jboss-jira] [JBoss JIRA] Commented: (JGRP-527) MuxChannel stuck
Bryce Alcock (JIRA)
jira-events at lists.jboss.org
Wed Jun 13 15:25:11 EDT 2007
[ http://jira.jboss.com/jira/browse/JGRP-527?page=comments#action_12365289 ]
Bryce Alcock commented on JGRP-527:
-----------------------------------
I was unable to reproduce it with the DrawMultiplexer as well.
However, I was able to consistently reproduce it in my application.
I tried 100 tests, and 98 times this event happend. It worked
correctly 2 times.
Unfortunately I am not really able to publish the proprietary code
that I am working with, and in fact I am not sure if I am able
to send it in confidence either (I will check on that)
A couple of things.
1. I added another use case, where I switch the MuxChannel with a JChannel,
for the one specific Mulipexer_ID that was Hanging, and it Never Hung as a JChannel (I have done at least 50 tests).
Infact it is working like a champ. Therefore, at this point I am moving forward
without the Muliplexer for that channel.
2. I have shown the code block 'public void fetchServiceInformation() throws Exception ...' (posted above)
to several engineers and all have agreed that if line 196 throws a timeoutexception, you can
end up in an infinite loop which is what it does in my case. So while it might not be reproducible
in the case of the simple DrawMultiplexer, it is reproducible in a my application.
3. I am willing to show you my ProtocolStack,
and I am willing to add logging statements anywhere you thing useful. But Mainly, I am just looking for Ideas
at this point. Also, trying to see if anyone else has had problems like this with the Multiplexer.
thanks for the help
Let me know how I can proceed
> 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
>
>
> [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