Broker 10.5 | webMethods Broker Documentation | webMethods Broker Client Java API Programmer's Guide | Using Broker Clients | Broker Connection Descriptors | Priority Ordering for Broker Queues
Priority Ordering for Broker Queues
Priority Ordering and Performance
The BrokerEvent.getPriority method and BrokerEvent.setPriority method allows you to order the documents in a queue by priority. To use priority ordering:
*A publisher assigns the priority to the messages that it publishes and
*The client enables the priority queue.
After you create a client with priority queue enabled, it is always priority enabled. You cannot turn the priority enabling off.
For Broker, implementation of priority messaging is based on server-side implementation of the priority queue. Each document is queued for delivery to the subscriber in the following order: (1) priority and (2) publication time. Documents are ordered by priority at the destination queue when the document is inserted into the destination client's queue, if that queue has priority ordering enabled. Priority ordering does not apply to forward queues, when documents are forwarded to subscriptions in territories, so there is a possibility that lower priority documents are delivered before incoming higher priority documents are delivered to the queue.
For priority values, Broker uses the same values according to JMS standards: priority values are from 0-9, where 0 is the lowest priority and 9 is the highest priority (expedited processing). The default value is 4.
Broker maintains the priorities through a set of priority cursors. These priority cursors are not persisted to disk, so the cursors are lost when you restart Broker. As a result, when you shut down Broker and restart it:
*All the priority cursors are reset to empty.
*All the existing documents in the queue are delivered with the default priority of 4.
*Any arriving documents are prioritized and delivered in priority order.
This means that after restarting the Broker, the priority of any new document places that document relative to the priority of the old documents, which now all have a default value of 4. For example, if you have a document A with a priority of 9 and you have to restart the Broker, document A and all of the documents still in the queue are now assigned the default priority of 4. When the queue receives any new documents after restarting the Broker, priority ordering applies to those new documents. So, if after restart, the new document B has a priority of 7, document B will now have a higher priority than document A, even though document A initially had a higher priority of 9.