3 Replies Latest reply on Jan 14, 2008 12:00 PM by Jeff Mesnil

    Something up with the in vm transport

    Tim Fox Master

      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.

      Any idea what this thread pool is doing?


        • 1. Re: Something up with the in vm transport
          Jeff Mesnil Master

           

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


          • 2. Re: Something up with the in vm transport
            Tim Fox Master

             

            "jmesnil" wrote:


            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.


            it should all run on the same thread - we don't want to introduce the overhead of unnecessary context switches.


            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.


            Agreed. No need for a timeout - just execute it on the same thread.

            • 3. Re: Something up with the in vm transport
              Jeff Mesnil Master

               

              "timfox" wrote:
              "jmesnil" wrote:


              Agreed. No need for a timeout - just execute it on the same thread.


              Done. I've checked it in the trunk in r3562.