[rabbitmq-discuss] Queue Look-ahead, et alia

Mon Feb 6 13:46:06 GMT 2012

Hi Paul,

On 06/02/12 12:37, Bell, Paul M. wrote:
> 1. Is it possible for a consumer to consume specific messages from a
> queue, e.g., one that contains a specific value (like a unique
> "request ID" that is part of each message)?

No, but if you are trying to match up requests with replies then
consider making use of a dedicated reply queue, in the way RPC does. The
6th tutorial explains in greater detail:
http://www.rabbitmq.com/tutorials/tutorial-six-java.html

> 2. Is it possible for a consumer to "run a queue," e.g., visit each
> message in the queue without removing it?

In theory a consumer could fetch many messages without acknowledgement,
acknowledge only those that match a filter and requeue the remainder.
Treating a queue like this strongly discouraged. The specification says
of basic.reject:

"The client MUST NOT use this method as a means of selecting messages to
process. "

If you require random access to messages then consider using a database,
or redesigning the message flow in such a way that consumers are able to
process all messages at the head of a queue.

> 3. Perhaps related to (1): does Rabbit support a kind of queue "peek"
> logic in the manner of Queue objects in C# and elsewhere? Peek allows
> one to obtain the queue head but leave it in place. (I know from
> previous threads on this list that message will remain in Q until
> expressly ack-ed, so maybe that's the answer.....)

A consumer can fetch and requeue a message from a queue, but (unless
there are other consumers consuming from the same queue) it will not
make any progress this way. The reason is that the consumer will see the
same message over and over.

> Behind my questions is something I learned re Microsoft's Azure
> design. Its message queues can be manipulated via RESTful URIs.
> Consequently, the contents of an Azure queue can be queried, just as
> one might query data in the persistence layer.

Data structures that can be browsed and manipulated in this way are not
strictly speaking queues. For performance reasons the internal data
structures in RabbitMQ have queues that do not permit random data access
patterns.

-Emile