CODEWITHSUNDEEP
javaconcurrencyjmstibco-emsems
Kevin
Kevin

Reputation: 6292

EMS Performance Issue

I am writing a service which serves stateless incoming requests. The requests are all mathematical calculation, which does not take very long to execute ( max 2ms).

I use Tibco EMS to communicate between client/server. A client library is provided which wraps the client side logic (e.g. convert data into EMS message etc) and send the request to a request queue. The server side processes the request and send the response into a separate queue. This works fine.

The server side is multi-threaded. A new thread is created when a new incoming request is received. Requests are therefore handled concurrently.

The server side uses one single EMS connection to the EMS server. However, because EMS Session is not thread safe, if I want to be able to write the response to EMS queue in each thread, I have to create one session for each thread using the connectionFactory. This degraded the performance.

The time spent on traffic is around 3-4ms, i.e. Time between a request is sent and a response is received is around 5-6ms.(3-4ms for transportation, marshal/unmarshal, 2ms for calculation).

Is there any solution which allows me to concurrently send to a EMS queue without creating two much JMS objects?

Are there any other important rules I need to follow to further optimize the service? Some basic optimization guidelines are already followed:

  1. Use CachedConnectionPool
  2. Send JMS message as NON_PERSISTANT
  3. Use one EMS connection for all requests.

Thank you very much.

Upvotes: 0

Views: 1123

Answers (1)

nochum
nochum

Reputation: 795

The behavior you are experiencing is not specific to EMS. The behavior is dictated by the JMS specification itself. Here is an extract from section 2.8 of the JMS Specification:

There are two reasons for restricting concurrent access to Sessions. First, Sessions are the JMS entity that supports transactions. It is very difficult to implement transactions that are multithreaded. Second, Sessions support asynchronous message consumption. It is important that JMS not require that client code used for asynchronous message consumption be capable of handling multiple, concurrent messages. In addition, if a Session has been set up with multiple, asynchronous consumers, it is important that the client is not forced to handle the case where these separate consumers are concurrently executing. These restrictions make JMS easier to use for typical clients. More sophisticated clients can get the concurrency they desire by using multiple sessions.

If you want to avoid the creation (and destruction) of that many objects, you might want to pre-create a pool of threads, and allocate a session to each thread up front.

Upvotes: 1

Related Questions