"timfox" wrote:
When I run in vm tests on TRUNK I notice a typical stack trace to a server method looks something like this:
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:397)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint$SessionAdvisedPacketHandler.handle(ServerSessionEndpoint.java:1803)
at org.jboss.messaging.core.remoting.PacketDispatcher.dispatch(PacketDispatcher.java:93)
at org.jboss.messaging.core.remoting.impl.invm.INVMSession$PacketDispatcherCallable.call(INVMSession.java:118)
at org.jboss.messaging.core.remoting.impl.invm.INVMSession$PacketDispatcherCallable.call(INVMSession.java:103)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
So the INVM transport is being used, but I would expect to see the execution done on the same thread all the way from the client.
That is not the case: the execution on the server-side is not done from the same thread. It uses a Executors.newSingleThreadExecutor() to run the code on the server-side.
I did that to provide the same behavior for the in vm optimization than for the remoting code. There is a given timeout for the server to reply to the client. If the server did not reply on time, an exception is raised.
The use of a Executors.newSingleThreadExecutor() is needed to apply a timeout on the Callable object.
To be frank, the more I think about it and the more I think I should get rid of the Executors.newSingleThreadExecutor() and not provide any timeout feature for the invm optimization.
Do you see a case where it'd make sense to keep this feature to avoid the client being stuck if the server is stuck (which should never happen anyway)? wdyt?
