2011-11-28 16 views
9

Tengo un programa simple de prueba RabbitMQ que encola aleatoriamente mensajes, y otro que los lee, todos usando Spring-AMQP. Si el consumidor fallece (por ejemplo, al matar un proceso sin tener la oportunidad de cerrar su conexión o canal), cualquier mensaje que no haya reconocido no se reconocerá para siempre.cuando muere un canal AMQP/RabbitMQ sin conexiones?

He visto varias referencias (por ejemplo, this question) que dicen que el canal muere cuando no tiene conexiones, y que los mensajes restantes no recuperados se volverán a entregar. Ese no es el comportamiento que veo, en su lugar recibo una creciente lista de canales marcados como IDLE y una lista creciente de conexiones marcadas en ejecución pero sin actividad.

¿Se requiere alguna configuración para observar que las conexiones están muertas una vez que el proceso ha sido cancelado?

EDIT: estaba corriendo el servidor RabbitMQ dentro de una máquina virtual VirtualBox, que al parecer no maneja las conexiones entrantes muertos correctamente a través de NAT. Esto funciona bien con el servidor mq ejecutándose directamente en el host físico.

+1

FYI: Estaba teniendo un problema similar cuando las colas exclusivas no se limpiaban en el intermediario de manera oportuna después de que el consumidor exclusivo fallece. Esto evitó que estos componentes con nombres deterministas comenzaran. Se resolvió estableciendo 'ConnectionFactory.RequestedHeartbeat' en un valor pequeño (segundos) – drstevens

Respuesta

3

Respondiendo a cerrar. Esto resulta no ser un problema real.

Estaba ejecutando el servidor rabbitmq dentro de una VirtualBox VM, que aparentemente no administra las conexiones entrantes muertas correctamente sobre NAT. Esto funciona bien con el servidor mq ejecutándose directamente en el host físico.

4

AMQP usa colas e intercambios. Publicas en un intercambio y enlazas colas para recibir mensajes de intercambios (puedes ver un short explanation en mi blog. Cuando creas una cola, puedes configurarla para que se elimine automáticamente, así como también, ¿cuánto tiempo permanecerá sin usar antes de que se active automáticamente? . borra Aquí es una cita de la QuickRef RabbitMQ:

queue.declare (cola de nombre-cola corta reservada-1,, bit pasiva, el bit duradera, poco exclusiva, bits de eliminación automática, no- wait no-wait, tabla argumentos) ➔ declare-ok

Soporte: declarar la cola completa, crear si es necesario.

Este método crea o comprueba una cola. Al crear una nueva cola, el cliente puede especificar varias propiedades que controlan la durabilidad de la cola y su contenido, y el nivel de uso compartido para la cola.

RabbitMQ implementa extensiones a la especificación AMQP que permite que el creador de una cola controle varios aspectos de su comportamiento.

Mensaje por cola TTL Esta extensión determina por cuánto tiempo un mensaje publicado en una cola puede vivir antes de que sea descartado por el servidor. El tiempo de vida se configura con el argumento x-message-ttl al parámetro argumentos de este método.

Queue Expiry Las colas se pueden declarar con un tiempo de arrendamiento opcional. El tiempo de concesión determina cuánto tiempo una cola puede permanecer sin usar antes de que sea borrado automáticamente por el servidor. El tiempo de concesión se proporciona como un argumento x expira en el parámetro argumentos de este método.

Colas duplicadas Hemos desarrollado una alta disponibilidad activa/activa para las colas . Esto funciona permitiendo que las colas se reflejen en otros nodos dentro de un clúster RabbitMQ. El resultado es que si falla un nodo de un clúster , la cola puede cambiar automáticamente a uno de los duplicados y continuar funcionando, sin la falta de disponibilidad del servicio.Para crear una cola duplicada, proporcione un argumento x-ha-policy en el parámetro argumentos de este método.

+0

No deseo que se elimine la cola, quiero que sea persistente. Pero también quiero que se reenvíen los mensajes no reconocidos (consumidos por procesos que murieron antes del reconocimiento). Son las conexiones/canales muertos los que deben eliminarse, no los mensajes. –

+2

ok ahora te tengo - necesitas crear una instancia de ConnectionParameters y establecer un latido (setRequestedHeardbeat) a un valor razonable (1 heartbeat miss cerrará el canal) Luego pasa eso al constructor de ConnectionFactory –

+0

@Arnon Rotem-Gal-Oz, setting 'RequestedHeartbeat' resolvió mi problema similar que se manifestaba por colas exclusivas que no se limpiaban en el corredor de manera oportuna. Esto impidió que los componentes declararan colas exclusivas con nombres deterministas desde el inicio. – drstevens

Cuestiones relacionadas