Why under certain conditions the 'Get JMS Queue Message' activity with IBM MQ does not perform as well as with other JMS vendors like TIBCO EMS?
Article ID: KB0090929
Updated On:
| Products | Versions |
|---|---|
| TIBCO ActiveMatrix BusinessWorks | - |
| Not Applicable | - |
Description
Resolution:
As per the JMS spec, a JMS Connection object encapsulates an open connection with a JMS provider, and it typically represents an open TCP/IP socket between a client and a provider's service daemon. A connection is a fairly heavyweight object and therefore most clients will share one connection for all messaging. Moreover, a JMS Session is a single-threaded context for producing and consuming messages. Although it may allocate provider resources outside the JVM, it is considered a lightweight JMS object that sits on top of a JMS connection.
Since IBM MQ treats each session as a TCP connection, every time you open and close a session it translates to opening and closing a TCP connection which is a costly operation. However, this is not the case with TIBCO EMS, with which a session is just a lightweight JMS object.
See FAQ1-7A08UK for more details.
Consider these different configurations for the GetJMS activity :
-Client acknowledge
-Auto acknowledge (or TIBCO Explicit), but the queue is set dynamically
-Auto acknowledge (or TIBCO Explicit), but the selector is set dynamically
The above configurations causes the GetJMS activity to create and close sessions for every invocation. Under such circumstances GetJMS activity will not perform well when the JMS vendor is IBM MQ. The performance is likely better with other vendors such as TIBCO EMS.
The only condition under which the session is cached is when you use Auto acknowledge (or TIBCO Explicit) and the queue or selector is NOT set dynamically. Under this circumstance you may not see real differences in the performance of the GetJMS activity between IBM MQ and other vendor implementations.
As per the JMS spec, a JMS Connection object encapsulates an open connection with a JMS provider, and it typically represents an open TCP/IP socket between a client and a provider's service daemon. A connection is a fairly heavyweight object and therefore most clients will share one connection for all messaging. Moreover, a JMS Session is a single-threaded context for producing and consuming messages. Although it may allocate provider resources outside the JVM, it is considered a lightweight JMS object that sits on top of a JMS connection.
Since IBM MQ treats each session as a TCP connection, every time you open and close a session it translates to opening and closing a TCP connection which is a costly operation. However, this is not the case with TIBCO EMS, with which a session is just a lightweight JMS object.
See FAQ1-7A08UK for more details.
Consider these different configurations for the GetJMS activity :
-Client acknowledge
-Auto acknowledge (or TIBCO Explicit), but the queue is set dynamically
-Auto acknowledge (or TIBCO Explicit), but the selector is set dynamically
The above configurations causes the GetJMS activity to create and close sessions for every invocation. Under such circumstances GetJMS activity will not perform well when the JMS vendor is IBM MQ. The performance is likely better with other vendors such as TIBCO EMS.
The only condition under which the session is cached is when you use Auto acknowledge (or TIBCO Explicit) and the queue or selector is NOT set dynamically. Under this circumstance you may not see real differences in the performance of the GetJMS activity between IBM MQ and other vendor implementations.
Issue/Introduction
Why under certain conditions the 'Get JMS Queue Message' activity with IBM MQ does not perform as well as with other JMS vendors like TIBCO EMS?
Feedback
Yes
No
Powered by
