RabbitMQ Java client Utilizzando DefaultConsumer vs QueueingConsumer

Question

1. DefaultConsumer
   mio DemoConsumer eredita da DefaultConsumer.
   Ho notato che lavorando in questo modo handleDelivery() viene richiamato da ThreadPool.
   (stampa Thread.currentThread(). GetName() Vedo pool-1-thread-1/2/3/4 eachtime.
   ho anche provato diverse volte e ho visto che l'ordine è stato salvato.
   Proprio per assicurarsi che - dal momento che diversi thread chiamano consegna manico - sarà lo pasticcio il mio ordine

2. QueueingConsumer
   Tutto il tutorial di Java utilizzare QueueingConsumer per consumare messaggi
   nella documentazione API è menzionato come una classe deprecato..
   Devo cambiare il mio codice per ereditarlo da DefaultConsumer usarlo? Il tutorial è scaduto?

Grazie.

Answer 1

Sì, DefaultConsumer utilizza un pool di thread interno che può essere modificato. Utilizzando ExecutorService come:

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

Leggi http://www.rabbitmq.com/api-guide.html “Opzioni di connessione avanzate”.

Come si può leggere dal “QueueingConsumer” doc:

Come tale, essa è ora al sicuro per implementare consumatore direttamente o per estendere DefaultConsumer.

Non ho mai utilizzato QueueingConsumer, perché non è gestito correttamente dagli eventi.

Come si può vedere qui:

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()); 
} 

Un problema tipico in questo caso è come chiudere la sottoscrizione, e una soluzione comune è quello di inviare un messaggio vicino taggato in host locale. In realtà non mi piace così tanto.

Se si estende DefaultConsumer invece, si può correttamente chiudere la sottoscrizione e il canale:

public class MyConsumer extends DefaultConsumer {...} 

poi

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 conclusione, non si deve preoccupare l'ordine messaggio perché se tutti funziona correttamente, l'ordine dei messaggi è corretto, ma penso che non si può presumere perché se c'è qualche problema, è possibile perdere l'ordine dei messaggi. Se è assolutamente necessario mantenere l'ordine dei messaggi, è necessario includere un tag sequenziale per ricostruire l'ordine dei messaggi dal lato del consumatore.

E si dovrebbe estendere DefaultConsumer.