JMS Resource and JMS Transport

Explained below are some usage recommendations when using JMS resource or JMS transport.

Usage Recommendations
Transport such as JMS can be throttled by limiting the number of sessions. JMS does not deliver more messages until some of the sessions have been acknowledged.
The combination of TIBCO Enterprise Message Service features Explicit Acknowledge and FlowLimit also exists. In this case, location of ack in process makes no difference.
When using Client Ack, the JMS session cannot receive a new message until the current message is acknowledged.
Using ActiveMatrix BusinessWorks you can configure multiple sessions to receive messages faster, and set number of sessions higher than the number of engine threads.
Acknowledge and confirm messages as soon as possible, to improve throughput.
By holding Client ack to the end of the process, you will block that session. This means you will slow down the rate at which ActiveMatrix BusinessWorks pulls messages from the JMS server, which will have to hold messages for a longer period of time.
With TIBCO Enterprise Message Service Explicit Ack, a single session is used to receive all messages. This mode allows for more efficient resource utilization, and provides even load distribution across multiple engines.
The best way to increase performance beyond the capability of a single engine is to distribute the load over multiple engines using a load-balanced transport such as JMS Queue, to distribute the work. External mechanisms exist to allow HTTP to be used for this purpose also.
Simple and Text JMS message types have the lowest processing overhead.
To design a long running process to fetch a message and process it, use Get JMS Queue message activity in a loop instead of Wait For JMS Queue message. In most cases, a JMS starter will be sufficient in this scenario.
If possible, choose NON_PERSISTENT as the delivery mode in replying to a JMS message.
For multiple JMS Receiver activities on an AppNode, the polling interval value has an impact on the CPU utilization of the AppNode. Lower the polling interval, higher is the CPU utilization, and higher the polling interval, lower the CPU utilization. In an environment where there are constraints on the available CPU resources, it is recommended that the polling interval value should be increased to lower the CPU consumption.