[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Something up with the in vm transport

[jmesnil]

"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?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119707#4119707

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119707