7.19 Notes on using Cosminexus JMS Provider

This section describes the notes on using Cosminexus JMS Provider.

Organization of this section
(1) Default Cosminexus JMS Provider operations
(2) Notes on the priority order of message processing
(3) Handling of messages with expired validity periods
(4) Order of the message properties
(5) Handling of the byte messages in the message properties
(6) Handling of messages in the BytesMessage interface
(7) Handling of messages in the dead message queue

(1) Default Cosminexus JMS Provider operations

By default, Cosminexus JMS Provider is operated as follows:

(2) Notes on the priority order of message processing

The sending of messages with Cosminexus JMS Provider does not guarantee that the messages with a high priority are executed first. For example, when three messages, 'message1', 'message2', and 'message3' with the priority order set as 1, 2, and 3 are sent from the producer, the messages might be processed in a different order, 'message1', 'message3', and 'message2' , with the consumer.

The differences in the priority order and processing order occur due to the following causes:

(3) Handling of messages with expired validity periods

If you change the system time of a computer on which a destination exists, the client might receive an expired message.

The validity period of the message is set by the method that sends a message to the JMSExpiration header field. If you change the system time settings by mistake, the messages with expired validity periods might be sent to the consumer.

(4) Order of the message properties

The processing order of the message properties is not guaranteed.

The message properties are not managed in a structure that maintains the order. Therefore, if, for example, there are properties 'property 1', 'property 2', and 'property 3', and the properties are sent to the destination in the same order, the properties are not necessarily processed in the same order. However, the properties and their values do not change before sending and when received.

(5) Handling of the byte messages in the message properties

Do not use the byte messages with the message properties.

The data of all the data types can be read with the byte messages. For example, if a message containing a long type value is invoked and processed with a short type method, the first two bytes are read successfully although the value is semantically invalid. This processing is prohibited with the other message data types.

With Cosminexus JMS Provider, the data types of the data are stored, and the data is managed so that the application of the correct transformation rules is supported.

(6) Handling of messages in the BytesMessage interface

When you use the writeUTF() method of the BytesMessage interface, do not write messages larger than 65,535 bytes. An exception occurs if a character string of length greater than 65,535 bytes is passed to the writeUTF() method.

(7) Handling of messages in the dead message queue

If rollback is repeated for a message received from the dead message queue, that message is not sent and remains in the dead message queue as is. To receive the messages remaining in the dead message queue again, restart CJMSP Broker.