Re: [Beepcore-java-users] Re: New to BEEP

[Huston <hu...@us...>]

On Sun, 2003-05-25 at 23:41, Walt Stoneburner wrote:
> "Grant Wood" <grant@na...> writes:
>   > When I do this, the listener on my "server" calls startChannel() so I
>   > assume the session is getting established fine.  Everything hangs at
>   > this point without any errors.
> 
> Huston / Grant,
> 
>    I've just spent the last few hours debugging the identical symptoms
>    using the latest beepcore-0.9.07.tgz on OS X using JRE 1.4.1_01.
> 
>    In my code, startChannel(), from the StartChannelListener interface,
>    has one job to do:
>                        channel.setMessageListener(this);
> 
>    It is this function that hangs, not startChannel().
> 
>    Stepping through the implementation shows that this call invokes
>    org.beepcore.beep.code.Channel.setMessageListener() with one
>    argument: ml.
> 
>    setMessageListener then turns around and immediately invokes the
>    PROTECTED signature of the same function,
>    org.beepcore.beep.core.Channel.setMessageListener(), although it
>    now takes two arguments: ml and blocking.
> 
>    blocking is set to true.
> 
>      When I step forward, getMessageListener() is called, which
>        ...sometimes it hangs indefinitely.
>        ...sometimes causes Java to report an array index out of bounds.
>        ...sometimes it proceeds to ThreadedMessageListener().
> 
>    If I intercept the thread of execution _before_ setMessageListener()
>    is invoked and coerce the argument blocking to false via the debugger,
>    the code seems to proceed without hanging.
> 
> 
>    What's curious is that setMessageListener(ml) always invokes
>    setMessageListener(ml,blocking) with blocking set to true.  To the 
> best
>    of my limited knowledge, the conditional code always executes the 
> positive
>    conditional path in Channel.java.
> 
>    Hope this helps in unwraveling Grant's mystery hang (and mine too).
> 
> -Walt Stoneburner, <wl...@ww...>

Walt,

Thanks for the help in debugging this. The one case where blocking is
set to false is for channel zero.

In looking at the code I'm not sure how this could happen. I could see a
runtime exception like ClassCastException or NullPointerException being
thrown if something went wrong. But I don't see how it could hang or
throw index out of bounds. I guess it could be a problem with the
jvm/jre, which would normally surprise me but I can't think of anything
else that would produce this behavior.

I'm willing to apply patches or make changes that are necessary to make
this work but unfortunately I need someone else to help with the
debugging work since I can't reproduce this problem.

FWIW, I'm in the process of cleaning up the frame delivery code which
will remove most of the code in question, including
ThreadedMessageListener.

--Huston