Message Compression Message Properties and Message Header Fields Message Ordering

3-2 Programming JMS for Oracle WebLogic Server

3.1.2 Serializing strings

Serializing Java strings is more expensive than serializing other Java primitive types. Strings are also memory intensive, they consume two bytes of memory per Character, and cannot compactly represent binary data integers, for example. In addition, the introduction of string-based messages often implies an expensive parse step in the application in order to process the String into something the application can make direct use of. Bytes, Stream, Map and even Object messages are therefore sometimes preferable to Text and XML messages. Similarly, it is preferable to avoid the use of strings in message properties, especially if they are large.

3.1.3 Server-side serialization

WebLogic JMS servers do not incur the cost of serializing non-persistent messages. Serialization of non-persistent message types is incurred by the remote client. Persistent are serialized by the server.

3.1.4 Selection

Using a selector is expensive. This consideration is important when you are deciding where in the message to store application data that is accessed via JMS selectors.

3.2 Message Compression

Compressing large messages in a JMS application can improve performance. This reduces the amount of time required to transfer messages across the network, reduces the amount of memory used by the JMS server, and, if the messages are persistent, reduces the size of persistent writes. Text and XML messages can often be compressed significantly. Of course, compression is achieved at the expense of an increase in the CPU usage of the client. Keep in mind that the benefits of compression become questionable for smaller messages. If a message is less than a few KB in size, compression can actually increase its size. The JDK provides built-in compression libraries. For details, see the java.util.zip package. For information on using JMS connection factories to specify the automatic compression of messages that exceed a specified threshold size, see Compressing Messages in the Performance and Tuning for Oracle WebLogic Server.

3.3 Message Properties and Message Header Fields

Instead of user-defined message properties, consider using standard JMS message header fields or the message body for message data. Message properties incur an extra cost in serialization, and are more expensive to access than standard JMS message header fields. Also, avoid embedding large amounts of data in the properties field or the header fields; only message bodies are paged out when paging is enabled. Consequently, if user-defined message properties are defined in an application, avoid the use of large string properties. For more information, see Section 2.4.6.1, Message Header Fields and Section 2.4.6.2, Message Property Fields. Best Practices for Application Design 3-3

3.4 Message Ordering

You should use the Message Unit-of-Order feature rather than Ordered Redelivery to guarantee ordered message processing. The advantages of Message Unit-of-Order over Ordered Redelivery are: ■ Ease of configuration. – Does not require a custom connection factory for asynchronous receivers, such as setting MessagingMaximum to 1 when using message-driven beans MDBs. – Simple configuration when using distributed destinations. ■ Preserves message order during processing delays. ■ Preserves message order during transaction rollback or session recovery. Oracle recommends applications that use Ordered Redelivery upgrade to Message Unit-of-Order. For more information, see Chapter 10, Using Message Unit-of-Order.

3.5 Topics vs. Queues