QueueingConsumer

Overview

Package

Class

Tree

Deprecated

Index

Help

PREV CLASS NEXT CLASS

FRAMES NO FRAMES

SUMMARY: NESTED | FIELD | CONSTR | METHOD

DETAIL: FIELD | CONSTR | METHOD

com.rabbitmq.client
Class QueueingConsumer

java.lang.Object
  com.rabbitmq.client.DefaultConsumer
      com.rabbitmq.client.QueueingConsumer

All Implemented Interfaces:: Consumer

public class QueueingConsumer
extends DefaultConsumer
extends DefaultConsumer

Convenience class: an implementation of Consumer with straightforward blocking semantics. The general pattern for using QueueingConsumer is as follows:

 // Create connection and channel.
 ConnectionFactory factory = new ConnectionFactory();
 Connection conn = factory.newConnection();
 Channel ch1 = conn.createChannel();

 // Declare a queue and bind it to an exchange.
 String queueName = ch1.queueDeclare().getQueue();
 ch1.queueBind(queueName, exchangeName, queueName);

 // Create the QueueingConsumer and have it consume from the queue
 QueueingConsumer consumer = new QueueingConsumer(ch1);
 ch1.basicConsume(queueName, false, consumer);

 // Process deliveries
 while (/* some condition * /) {
     QueueingConsumer.Delivery delivery = consumer.nextDelivery();
     // process delivery
     ch1.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
 }

For a more complete example, see LogTail in the test/src/com/rabbitmq/examples directory of the source distribution.

deprecated QueueingConsumer was introduced to allow applications to overcome a limitation in the way Connection managed threads and consumer dispatching. When QueueingConsumer was introduced, callbacks to Consumers were made on the Connection's thread. This had two main drawbacks. Firstly, the Consumer could stall the processing of all Channels on the Connection. Secondly, if a Consumer made a recursive synchronous call into its Channel the client would deadlock.

QueueingConsumer provided client code with an easy way to obviate this problem by queueing incoming messages and processing them on a separate, application-managed thread.

The threading behaviour of Connection and Channel has been changed so that each Channel uses a distinct thread for dispatching to Consumers. This prevents Consumers on one Channel holding up Consumers on another and it also prevents recursive calls from deadlocking the client.

As such, it is now safe to implement Consumer directly or to extend DefaultConsumer.

Nested Class Summary
`static class`	`QueueingConsumer.Delivery` Encapsulates an arbitrary message - simple "bean" holder structure.

Constructor Summary
`QueueingConsumer(Channel ch)`
`QueueingConsumer(Channel ch, java.util.concurrent.BlockingQueue<QueueingConsumer.Delivery> q)`

Method Summary
`void`	`handleCancel(java.lang.String consumerTag)` No-op implementation of `Consumer.handleCancel(String)`
`void`	`handleDelivery(java.lang.String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body)` No-op implementation of `Consumer.handleDelivery(java.lang.String, com.rabbitmq.client.Envelope, com.rabbitmq.client.AMQP.BasicProperties, byte[])`.
`void`	`handleShutdownSignal(java.lang.String consumerTag, ShutdownSignalException sig)` No-op implementation of `Consumer.handleShutdownSignal(java.lang.String, com.rabbitmq.client.ShutdownSignalException)`.
`QueueingConsumer.Delivery`	`nextDelivery()` Main application-side API: wait for the next message delivery and return it.
`QueueingConsumer.Delivery`	`nextDelivery(long timeout)` Main application-side API: wait for the next message delivery and return it.

Methods inherited from class com.rabbitmq.client.DefaultConsumer
`getChannel, getConsumerTag, handleCancelOk, handleConsumeOk, handleRecoverOk`

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

Constructor Detail