Managing Client Threads

Using client threads effectively requires that you balance performance,
throughput, and resource needs. To do this, you need to understand JMS restrictions
on thread usage, what threads Message Queue allocates for itself, and the
architecture of your applications. This section addresses these issues and
offers some guidelines for managing client threads.

JMS Threading Restrictions

The Java Messaging Specification mandates that a session not be operated
on by more than one thread at a time. This leads to the following restrictions:

A session may not have an asynchronous consumer and a synchronous
consumer.

A session that has an asynchronous consumer can only produce
messages from within the onMessage() method (the message
listener). The only call that you can make outside the message listener is
to close the session.

A session may include any number of synchronous consumers,
any number of producers, and any combination of the two. That is, the single-thread
requirement cannot be violated by these combinations. However, performance
may suffer.

The system does not enforce the requirement that a session be single
threaded. If your client application violates this requirement, you will get
a JMSIllegalState exception or unexpected results.

Thread Allocation for Connections

When the Message Queue client runtime creates a connection, it creates
two threads: one for consuming messages from the socket, and one to manage
the flow of messages for the connection. In addition, the client runtime creates
a thread for each client session. Thus, at a minimum, for a connection using
one session, three threads are created. For a connection using three sessions,
five threads are created, and so on.

Managing threads in a JMS application
often involves trade-offs between performance and throughput. Weigh the following
considerations when dealing with threading issues.

When you create several asynchronous message consumers in
the same session, messages are delivered serially by the session thread to
these consumers. Sharing a session among several message consumers might starve
some consumers of messages while inundating other consumers. If the message
rate across these consumers is high enough to cause an imbalance, you might
want to separate the consumers into different sessions. To determine whether
message flow is unbalanced, you can monitor destinations to see the rate of
messages coming in. See Chapter 4, Using the Metrics Monitoring API.

You can reduce the number of threads allocated to the client
application by using fewer connections and fewer sessions. However, doing
this might slow your application’s throughput.

You might be able to use certain JVM runtime options to improve
thread memory usage and performance. For example, if you are running on the
Solaris platform, you may be able to run with the same number (or more) threads
by using the following vm options with the client: Refer
to the JDK documentation for details.

Use the Xss128K option to decrease the
memory size of the heap.

Use the xconcurrentIO option to improve
thread performance in the 1. 3 VM.