I just re-ran this test with everything inside of the same vm and did not
run into any hangs. I also turned up the client poll rate to sleep only for
a second (instead of 1 minute). I am running even bigger tests now, still
all in the same vm. After that completes, if it completes I should say, I
will try moving the router outside of the vm. I am guessing that will fail.
If it does, I am going to try using the JBossMQ jars from the last release
that our software runs under (I think that is a 2.3, but I am not sure).
--jason
On Fri, 13 Jul 2001, Jason Dillon wrote:
> I am still seeing a hang in EntityInstanceInterceptor =( I think I am
> starting to understand the problem more, which is good. Unfortunately I
> still don't have a good idea for which chunk of code is at fault.
>
> In reference to the complicated scenario that I explained before, I might
> be able to provide some insight. I think that there are a few different
> problems here.
>
> I re-ran a large test but removed the last vm and mdb that actually
> processed the requests. This works with no hangs. I then started up the
> end MDB to process all of the messages from the router, it looks like it
> processed about 16 requests then hung.
>
> The MDB thread will hang calling a method from some internal code, which
> will wait() for a notification. Another internal thread is invoking a call
> back which will collect the results of the work and send the response. This
> is hanging in socket io in the JBossMQ RMI IL:
>
> <snip>
> at java.net.SocketInputStream.socketRead(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:86)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:204)
> at java.io.DataInputStream.readByte(DataInputStream.java:222)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:186)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
> at
> org.jbossmq.distributed.server.DistributedJMSServerRMIImpl_Stub.addMessage(Unknown
> Source)
> at org.jbossmq.SpyConnection.sendToServer(SpyConnection.java:373)
> at org.jbossmq.SpySession.sendMessage(SpySession.java:362)
> at org.jbossmq.SpyQueueSender.send(SpyQueueSender.java:103)
> at org.jbossmq.SpyQueueSender.send(SpyQueueSender.java:62)
> at
> <truncated/>
> </snip>
>
> This will essentially lock the vm (it is not spinning or wedged, but will
> not do anything else). Since the internal code is waiting for this call
> back to finish before it call notify, the MDB thread TX will timeout.
>
> The first odd thing is that when it times out a message is logged, but the
> thread still hangs. Should it be interrupted or something?
>
> Now I am still not sure why, then all of these complenets are running
> together that when the end MDB hangs that request creation beans also hang
> (in the EntityInstanceInterceptor). I think that this might be releated to
> the JBossMQ changes, since I think that both vms might be hung waiting on
> some io from JBossMQ.
>
> I might try running this all inside of one vm to see if the same problem
> happens, which I would guess it would. I might also try turning up the
> client poll rate again, with the end MDB turned off to see if there is still
> a hang due to contention (as I was seeing before).
>
> So I think we are making progress, but it looks like there is still
> something wrong.
>
> What should happen when a transaction times out?
>
> --jason
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
