2011-11-28 13 views
9

Ho un semplice programma di test RabbitMQ che esegue l'aggancio casuale dei messaggi e un altro li legge tutti utilizzando Spring-AMQP. Se il consumatore muore (ad esempio uccidendo un processo senza avere la possibilità di chiudere la connessione o il canale), tutti i messaggi che non ha riconosciuto sembrano non essere riconosciuti per sempre.quando muore un canale AMQP/RabbitMQ senza connessioni?

Ho visto un numero di riferimenti (ad esempio this question) che dicono che il canale muore quando non ha connessioni e che i restanti messaggi non bloccati saranno riconsegnati. Questo non è il comportamento che vedo, ma ottengo un elenco crescente di canali contrassegnati come IDLE e un elenco crescente di connessioni contrassegnate come in esecuzione ma senza attività.

Esiste qualche configurazione necessaria per notare che le connessioni sono morte una volta che il processo è stato interrotto?

EDIT: stavo correndo il server RabbitMQ all'interno di una macchina virtuale VirtualBox, che a quanto pare non gestisce le connessioni in entrata morti correttamente su NAT. Funziona perfettamente con il server di mq che esegue direttamente sull'host fisico.

+1

FYI: Avevo un problema simile in cui le code esclusive non venivano pulite sul broker in modo tempestivo dopo la morte del consumatore esclusivo. Ciò ha impedito l'avvio di questi componenti con nomi deterministici. È stato risolto impostando 'ConnectionFactory.RequestedHeartbeat' su un valore piccolo (secondi) – drstevens

risposta

3

Risposta alla chiusura. Questo risulta non essere un vero problema.

Stavo eseguendo il server rabbitmq all'interno di una VM VirtualBox, che a quanto pare non gestisce correttamente le connessioni in entrata sul NAT. Funziona perfettamente con il server di mq che esegue direttamente sull'host fisico.

4

AMQP utilizza code e scambi. Pubblichi su uno scambio e leghi le code per ottenere messaggi dagli scambi (puoi vedere un short explanation sul mio blog. Quando crei una coda puoi impostarlo per l'eliminazione automatica e quanto tempo rimarrà inutilizzato prima che venga automaticamente . cancella Ecco una citazione dal QuickRef RabbitMQ:

queue.declare (coda di coda nome breve riservato-1,, bit passiva, bit durevole, po 'esclusiva, po Autoeliminazione, no- attendere no-wait, tabella argomenti) ➔ declare-ok

Supporto: coda dichiarazione completa, creare se necessario

Questo metodo crea o controlla una coda. Quando si crea una nuova coda, il client può specificare varie proprietà che controllano la durata di la coda e il suo contenuto e il livello di condivisione per la coda.

RabbitMQ implementa estensioni alle specifiche AMQP che consentono a il creatore di una coda di controllare vari aspetti del suo comportamento.

Per-Message Queue TTL Questa estensione determina per quanto tempo un messaggio pubblicato a una coda può vivere prima che venga eliminato dal server. Il time-to-live è configurato con l'argomento x-message-ttl sul parametro argomenti di questo metodo.

Scadenza coda Le code possono essere dichiarate con un lease time opzionale. Il tempo di leasing determina per quanto tempo una coda può rimanere inutilizzata prima che sia automaticamente cancellata dal server. Il lease time è fornito come argomento x-expires nel parametro arguments di questo metodo.

Code con mirroring Abbiamo sviluppato una disponibilità elevata attiva/attiva per le code . Questo funziona consentendo alle code di essere specchiate su altri nodi all'interno di un cluster RabbitMQ. Il risultato è che se un nodo di un cluster fallisce, la coda può automaticamente passare a uno dei mirror e continuare a funzionare, senza alcuna indisponibilità del servizio.Per creare una coda con mirroring, fornire un argomento x-ha-policy negli argomenti parametro a questo metodo.

+0

Non voglio che la coda sia cancellata, voglio che sia persistente. Ma voglio anche che i messaggi non riconosciuti (consumati dai processi che sono morti prima del riconoscimento) siano riconsegnati. Sono le connessioni/i canali morti che devono essere eliminati, non i messaggi. –

+2

ok ora ho capito: è necessario creare un'istanza ConnectionParameters e impostare un heartbeat (setRequestedHeardbeat) su un valore ragionevole (1 heartbeat miss chiuderà il canale) Quindi passare al costruttore ConnectionFactory –

+0

@Arnon Rotem-Gal-Oz, impostazione 'RequestedHeartbeat' ha risolto il mio problema simile che si stava manifestando con code esclusive non ripulite sul broker in modo tempestivo. Ciò ha impedito l'avvio di componenti che dichiarano code esclusive con nomi deterministici. – drstevens

Problemi correlati