Number of threads per jms client connection

[bartvh]

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?

[timfox]

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?

[bartvh]

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