I’ve had a look at product documentation 9-5-SP1_Using_Integration_Server_to_Build_a_Client_for_JMS, 9-5-SP1_Integration_Server_Built-In_Services_Reference and release-notes-9.5.2 (available under /nirvana/doc. These documents confirms support for JMS priority. However I build a small POC and it delivers messages on FIFO basis.
POC Detail # Components:
Flow service to set JMS priority in pub.jms.send
JMS Trigger listening for message with processing set to concurrent but max 1 thread.
Flow service that JMS trigger would invoke and pass on the JMS Message # Implementation logic:
JMS Trigger is disabled to stop the messages from being processed. This would allow 1st Flow service above to publish some JMS messages with different priority and and in different order.
Via UMS Enterprise Manager, I can spool on JMS Topic to see that messages are all waiting and that they have correct priority setting as per service publishing it.
I then go in and enable trigger which invokes flow service which logs the JMSMessage/header/priority field from message using debugLog. # Observation:
Subscription trigger seem to receive messages in exact order of publishing. Priority field seem to have been ignored.
Can you please advice if I’ve missed anything or that problem is with product? I can then advice client accordingly.
I did read that. However I also found in UMS document release-notes-9.5.2 (and 9.6) page 9 suggests that priority is supported since version 9.0. The last line in that para suggests that Integration Server should support it too.
Priority Messaging
Universal Messaging 9.0 includes support for Priority Messaging. This is the ability to process higher priority messages before lower priority messages in the client and server. The priority handling mechanism within the Universal Messagingserver exists at various levels such that when messages are placed into a client’s queue, they will be processed according to the priority, i.e. if there are already 5 messages with priorities 0-4 in the queue, and
another message with priority 9 is added to the queue, then the next message to be pulled from the queue will be the priority 9 message. The internals of the prioritization mechanism have been written so they are also used within the client APIs, such that the client APIs will also attempt to deliver messages to the client applications based on their priority.
We have been discussing this with R&D and have done more tests, so I thought I’d keep you up to date.
We got the following details from R&D. Priority messaging across all APIs is supported in 9.5.2. UM prioritises messages dynamically on a per-client basis. This is done using a number of priority queues at certain points in the messaging system. These are (1) directly above the network layer and (2) directly before client callbacks. The priority queues at (1) ensure that in conditions where messages are not immediately written to the network the highest priority messages are delivered first. The queues at (2) ensure that in conditions where the trigger/callback which processes messages will receive the highest priority messages in cases where the trigger cannot process an incoming message immediately.
We tried a java program which sent and received messages and this worked ok. I also tried sending from IS and receiving in java and vice versa, sending from java and receiving from IS. In both cases the messages were prioritized and received in the correct order. It is only when using IS as both the sender and receiver that it appears not to work as expected.
Final response From SAG support was that Priority works if UMS client is build using Java. Integration Server doesn’t support priority (as is documented and highlighted by other forum member). There is no roadmap to support it in other versions.
I was recommnded to use brainstrom to raise feature request
Hope it helps everyone interested in JMS priority over UMS/IS…