2 Replies Latest reply on Aug 9, 2007 7:45 AM by Bart Vanhaute

    Number of threads per jms client connection

    Bart Vanhaute Newbie

      I realize this is the developers forum, and not a place to ask user questions, but I think this one is indeed much more design related.

      Because in our setup we have a 'gateway'-like jms client that needs to create many sessions, we need to be careful about the resources a jms client connection/session needs. I was looking at the number of threads that are created per connection, per session, ...

      I noticed that each connection creates two threads : a "control: Socket[....]" thread and a "Timer-..." thread.

      I can see understand that the first one is unavoidable without a complete rewrite of jboss-remoting to use nio and select.
      The second timer thread should be easier to avoid: such a thread is created because each connection creates a java.util.Timer object. However, I don't think there is a real reason to create a new Timer object each time; according to the java api docs, a Timer object is capable of handling many scheduled tasks as long as the tasks finish quick.

      Now, after stopping one of the nodes of the cluster, I see the number of threads increase: there are new threads called " WorkerThread#..[....]" with the following stack trace:
      java.net.SocketInputStream.socketRead0(Native Method)
      java.net.SocketInputStream.read(SocketInputStream.java:129)
      java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
      java.io.BufferedInputStream.read(BufferedInputStream.java:235)
      java.io.FilterInputStream.read(FilterInputStream.java:66)
      org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:810)
      org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:506)
      org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
      org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)

      This looks rather odd for a jms client. Is this the callback channel of the bi-socket protocol?

        • 1. Re: Number of threads per jms client connection
          Tim Fox Master

          Hello Bart

          "bartvh" wrote:

          I noticed that each connection creates two threads : a "control: Socket[....]" thread and a "Timer-..." thread.


          The extra timer is due to a bug in the version of remoting used in AS 4.2.0. Ron has already fixed this and this new remoting jar will be available soon.


          I can see understand that the first one is unavoidable without a complete rewrite of jboss-remoting to use nio and select.


          Yes indeed, blocking IO is one of our major bugbears and the reason why we will be concentrating effort on a completely new socket transport based on Apache MINA for JBM 2.0.


          Now, after stopping one of the nodes of the cluster, I see the number of threads increase: there are new threads called " WorkerThread#..[....]" with the following stack trace:
          java.net.SocketInputStream.socketRead0(Native Method)
          java.net.SocketInputStream.read(SocketInputStream.java:129)
          java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
          java.io.BufferedInputStream.read(BufferedInputStream.java:235)
          java.io.FilterInputStream.read(FilterInputStream.java:66)
          org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:810)
          org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:506)
          org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
          org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)

          This looks rather odd for a jms client. Is this the callback channel of the bi-socket protocol?


          I'm not sure what is going on there - maybe Ron can advise?

          • 2. Re: Number of threads per jms client connection
            Bart Vanhaute Newbie

             

            "timfox" wrote:
            Yes indeed, blocking IO is one of our major bugbears and the reason why we will be concentrating effort on a completely new socket transport based on Apache MINA for JBM 2.0.

            Nice to hear. I hadn't heard about MINA before. Looks very promising. Our gateway itself is based on the original SEDA SandStorm. Though MINA has a more high-level api, the structure seems very similar. And I see good performance figures from that framework.