Support for JMS message priorities in Netweaver AS 6.4

[Former Member]

We need to support message priorities when we send a message to a Queue using JMS. Some messages are to be treated as emergencies and must be processed before the messages currently enqueued. While we can set the message priority this does not seem to have any effect. The J2EE specs apparently leave the interpretation of what a message priority does to the implementor and states that implementors must make "best efforts" to process messages by priority or priority group.

However, we were not able to get the desired behavior on SAP.

Other implementors seem to support various schemes to manage the order through which messages are processed on the queue. For example, in WebLogic you can do the following (according to the documentation):

"As messages arrive on a specific destination, by default they are sorted in FIFO (first-in, first-out) order, which sorts ascending based on each message's unique JMSMessageID. However, you can use a destination key to configure a different sorting scheme for a destination, such as LIFO (last-in, first-out)."

Is there a way to achieve message ordering in Netweaver 6.4 message queues (point to point).

[former_member187702 · Accepted solution]

Hi Laurent

You can set the priority level in either of two ways.

1.You can use the setPriority method of the MessageProducer interface to set the priority level for all messages sent by that producer.

2. You can use the long form of the send or the publish method to set the priority level for a specific message. The third argument sets the priority level. For example, the following publish call sets the priority level for message to 3:

topicPublisher.publish(message, DeliveryMode.NON_PERSISTENT, 3, 10000);

The ten levels of priority range from 0 (lowest) to 9 (highest). If you do not specify a priority level, the default level is 4. A JMS provider tries to deliver higher-priority messages before lower-priority ones but does not have to deliver messages in exact order of priority.

Regards

[Former Member · Accepted solution]

Thanks Shilpa but we have worked with the API and used the various methods you have identified but unfortunately, as far as we could see, the Netweaver implementation does not deliver messages by priority. Whatever priority we set, they are still delivered in FIFO order.

That was precisely our point: we have not been able to get message ordering by priority to have any effect. We have questions as to whether the Netwaver actually "tries to deliver higher-priority messages before lower-priority ones"

[Former Member · Accepted solution]

Hi Laurent,

Yes it does try. Two problems that you might have stumbled upon :

1) You have called the API method -- message.setJMSPriority(X).

to set the priority. That will not set the sending priority as per the JMS spec, I think the spec could have been better in that way

2) There is something else that the NetWeaver does automatically for every consumer. In BEA since you are familiar with it, it is called "Enabled Prefetch Mode for Consumers". In other words if you have 1000 messages already in the queue and you have created a receiver in a standalone client and started the connection it will receive some of the messages automatically. When you a message is given to the application it will be done so WITHOUT hit to the server. I.e. if you send the 1001-st high prio message it will be delivered after the prefetched messages are consumed. Let's say after the 400-th message...

By default the prefetched messages will be those who make 512K total size (to disallow OOM on the JVM of the client I guess). That can be configured though.

I would advise you the following experiment - sent two messages one low, one high prio. When you have NO queue consumer. Reboot the server (just to be sure) and register a consumer. You should see them in the opposite way.

Btw, if you are having messages that must be treated in two different way, then maybe you can use two different queues ? It would be also easier for the monitoring for example ....Just my two cents.

Best Regards

Peter

[Former Member · Accepted solution]

Peter,

After quite a bit of tinkering we finally managed to get the desired behavior thanks to the information you supplied. In fact the way we are configured the system is that we set clientConsumerBuffer property to 0 in the JMS Provider service.