Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Info

This page applies to Java Broker versions before 0.18. For the master copy of this documentation see the Other Queue Types section in the Java documentation

General Information

The Qpid M3 0.7 release introduces priority queues Last Value Queues (LVQs) into the Java Messaging Broker, supporting JMS clients who wish to make use of priorities in their messaging implementation.There are some key points around the use of priority queues in Qpid, discussed in the sections belowBroker. The LVQ implementation in the Java Broker provides a superset of the behaviour of the LVQ in the C++ Broker. It is hoped that later revisions of the C++ Broker will adopt the same enhanced semantics.

LVQ Semantics

In an LVQ messages in the queue are be "replaced" by newer messages having the same value for some specified header. An example of an LVQ might be where a queue representing prices on a stock exchange: when you first consume from the queue you get the latest quote for each stock, and then as new prices come in you are sent only these updates.

...

Receiving messages from an LVQ

Qhen When receiving messages from an LVQ you may wish to change the default pre-fetch setting for your client. With a large pre-fetch value message will be sent from the queue as soon as they arrive, and then be buffered on the client. This may lead to cases where newer versions of messages are buffered behind older versions within the client. With a lower pre-fetch value the broker has an opportunity to replace older versions of the message with newer versions before sending to the client.

...

Setting the Qpid pre-fetch to 1 for your client means that message priority conflation will be honoured by the Qpid broker as it dispatches messages to your client. A default for all client connections can be set via a system property:

...

There is a slight performance cost here if using the receive() method and you could test with a slightly higher pre-fetch (up to 10) if the trade-off between throughput and prioritisation conflation is weighted towards the former for your application. (If you're using OnMessage() then this is not a concern.)

...

If you are using the receive() method to consume messages then you should also only use one consumer per session with priority queues. If you're using onMessage() then this is not a concern.

...