Pass message payload by reference: Potential benefits for each processing step

WAS v8.5 > WebSphere applications > Messaging resources > Default messaging > How JMS applications connect to a messaging engine on a bus > Why and when to pass the JMS message payload by reference
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.
CAUTION:
The parts of the JMS Specification that are bypassed by these properties are defined to ensure message data integrity. Any of your JMS applications that use these properties must strictly follow the rules that are described in the topic Why and when to pass the JMS message payload by reference, or you risk losing data integrity.
To pass the message payload by reference, you set the following properties on connection factories and activation specifications:

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.

Potential performance benefits for each processing step taken by your producer, consumer or forwarder application. The first column of the table lists the processing steps for the objects and bytes messages. The second column indicates if there is a possibility for performance improvement. The third column provides a brief explanation about the processes and the properties.

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:

The producer of the forwarded message has the producerDoesNotModifyPayloadAfterSet property enabled and is in the same JVM as the forwarder application.
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 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.

Related concepts:

Why and when to pass the JMS message payload by reference

Related

Configure a unified connection factory for the default messaging provider
Configure a queue connection factory for the default messaging provider
Configure a topic connection factory for the default messaging provider
Configure an activation specification for the default messaging provider

Reference:

createSIBJMSActivationSpec command
modifySIBJMSActivationSpec command
createSIBJMSConnectionFactory command
modifySIBJMSConnectionFactory command

Related information:

Default messaging provider unified connection factory [Settings]
Default messaging provider queue connection factory [Settings]
Default messaging provider topic connection factory [Settings]
JMS activation specification [Settings]

+
Search Tips | Advanced Search

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: The producer of the forwarded message has the producerDoesNotModifyPayloadAfterSet property enabled and is in the same JVM as the forwarder application. 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 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.