Pass message payload by reference: Potential benefits for each processing step
For each processing step taken by your JMS messaging application, check this table to see when and why there is a potential performance benefit in enabling the pass message payload by reference properties on the associated connection factory or activation specification.
When large object messages or bytes messages are sent, the cost in memory and processor use of serializing, deserializing, and copying the message payload can be significant. If you enable the pass message payload by reference properties on a connection factory or activation specification, you tell the default messaging provider to override the JMS 1.1 specification and potentially reduce or bypass this data copying.
- producerDoesNotModifyPayloadAfterSet (for connection factories) or forwarderDoesNotModifyPayloadAfterSet (for activation specifications)
- When this property is enabled, object or bytes messages produced by the connection factory or forwarded through the activation specification are not copied when set into the message and are only serialized when absolutely necessary. Applications sending such messages must not modify the data after it has been set into the message.
- consumerDoesNotModifyPayloadAfterGet
- When this property is enabled, object messages received through the connection factory or activation specification are only serialized when absolutely necessary. The data obtained from those messages must not be modified by applications.
Processing step | Is there potential for performance improvement? | Explanation |
---|---|---|
Object messages with producer and consumer applications | ||
An object message is sent to a consumer application in the same JVM. The producerDoesNotModifyPayloadAfterSet and consumerDoesNotModifyPayloadAfterGet properties are both enabled. | Yes | Under certain conditions, the payload object is passed by reference to the
consumer application. If the message is not persistent or transacted, and the consumer application is immediately available, the payload object might never be serialized. |
An object message is produced with the producerDoesNotModifyPayloadAfterSet property enabled, then received by a consumer application for which the consumerDoesNotModifyPayloadAfterGet property is not enabled. | No | No benefit is gained because the consumer application does not have the consumerDoesNotModifyPayloadAfterGet property enabled. |
An object message is sent to a single consumer application in a different JVM. The producerDoesNotModifyPayloadAfterSet and consumerDoesNotModifyPayloadAfterGet properties are both enabled. | No | No benefit is gained because the single consumer application is in another JVM. |
An object message is received by multiple consumer applications (a topic) that all have the consumerDoesNotModifyPayloadAfterGet property enabled and are all running in the same JVM. | Yes | All consumer applications with the consumerDoesNotModifyPayloadAfterGet property enabled might receive a reference to the same object, though this is not guaranteed. |
Object messages with forwarder applications | ||
An object message is forwarded and the forwarder application accesses the payload of the message. The consumerDoesNotModifyPayloadAfterGet and producer/forwarderDoesNotModifyPayloadAfterSet properties are enabled. | Yes | There is a potential performance benefit in the following cases:
|
An object message is forwarded and the forwarder application accesses the payload of the message. Only the producer/forwarderDoesNotModifyPayloadAfterSet property is enabled. | Yes | There is a potential performance benefit if the consumer of the forwarded message has the consumerDoesNotModifyPayloadAfterGet property enabled and is in the same JVM as the forwarder application. |
An object message is forwarded and the forwarder application does not access the payload of the message. | No | If the payload of the object message is not accessed by the forwarder application then the producer/forwarderDoesNotModifyPayloadAfterSet and consumerDoesNotModifyPayloadAfterGet properties have no effect for the forwarder application. Benefits gained from the original producer application and ultimate consumer application are maintained. |
Object messages with mediations | ||
An object message is sent to a mediated service integration bus destination. | No | If the object message is sent to a mediated destination then no performance benefit is gained by enabling the producerDoesNotModifyPayloadAfterSet property. |
Bytes messages with consumer applications | ||
A bytes message is sent to any consumer application. The producerDoesNotModifyPayloadAfterSet property is enabled. | Yes | The part of the JMS specification that mandates copying the data on setting into the message is bypassed, saving a copy of the bytes data. |
A bytes message is received with the consumerDoesNotModifyPayloadAfterGet property enabled. | No | The JMS API does not allow bytes data to be passed by reference back to consumer code (BytesMessage.readBytes methods). |
A bytes message is received by multiple consumers (a topic) that all have the consumerDoesNotModifyPayloadAfterGet property enabled. | No | The JMS API does not allow bytes data to be passed by reference back to consumer code (BytesMessage.readBytes methods). |
Bytes messages with forwarder applications | ||
A bytes message is forwarded. | No | There is no benefit gained from enabling any of the pass message payload by reference properties. |