Geek Answers Handbook

Java RabbitMQ Client using DefaultConsumer vs QueueingConsumer

  • Defaultconsumer
    My DemoConsumer inherits from DefaultConsumer.
    I noticed that working in this way handleDelivery () is called from ThreadPool.
    (print Thread.currentThread (). getName () I see pool-1-thread-1/2/3/4 every time.
    I also checked it several times and saw that the order was saved.
    Just to make sure that since different threads cause the descriptors to be delivered, will this ruin my order?

  • Queueingconsumer
    All java tutorials use QueueingConsumer to use messages.
    In API Docs, it is referred to as an obsolete class.
    Should I change my inheritance code using DefaultConsumer, use it? Outdated tutorial?

Thanks.

+7
multithreading rabbitmq messaging
source share
1 answer

Yes, DefaultConsumer uses an internal thread pool that can be changed. Using ExecutorService as:

 ExecutorService es = Executors.newFixedThreadPool(20); Connection conn = factory.newConnection(es);

Read the http://www.rabbitmq.com/api-guide.html Advanced Connection Settings.

As you can read from the "QueueingConsumer" doc :

Thus, it is now safe to implement the Consumer directly or extend the DefaultConsumer.

I have never used QueueingConsumer because it is not event driven.

As you can see here:

 QueueingConsumer consumer = new QueueingConsumer(channel); channel.basicConsume(QUEUE_NAME, true, consumer); while (true) { QueueingConsumer.Delivery delivery = consumer.nextDelivery(); /// here you are blocked, waiting the next message. String message = new String(delivery.getBody()); }

A typical problem in this case is how to close the subscription, and a common workaround is to send the private message tag on the local host. I don’t really like it.

If you extend the DefaultConsumer , you can properly close the subscription and channel:

 public class MyConsumer extends DefaultConsumer {...}

then

 public static void main(String[] args) { MyConsumer consumer = new MyConsumer (channel); String consumerTag = channel.basicConsume(Constants.queue, false, consumer); System.out.println("press any key to terminate"); System.in.read(); channel.basicCancel(consumerTag); channel.close(); ....

In conclusion, you do not have to worry about the message order, because if everything works correctly, the message order is correct, but I think you can’t accept it, because if there is any problem, you can lose the message order. If you absolutely need to maintain message order, you must include a sequential tag to restore message order on the consumer side.

And you have to expand DefaultConsumer.

+12
source share

More articles:


All Articles