queuebind - rabbitmq rpc java
¿Por qué mis canales RabbitMQ siguen cerrando? (4)
Estoy depurando un código Java que utiliza el PDI de Apache para extraer datos de documentos de Microsoft Office. Ocasionalmente, se encuentra con un gran documento y se bloquea el POI cuando se queda sin memoria. En ese momento, intenta publicar el error en RabbitMQ, para que otros componentes puedan saber que este paso falló y realizar las acciones apropiadas. Sin embargo, cuando intenta publicar en la cola, obtiene una com.rabbitmq.client.AlreadyClosedException (clean connection shutdown; reason: Attempt to use closed channel)
.
Aquí está el código del controlador de errores:
try {
//Extraction and indexing code
}
catch(Throwable t) {
// Something went wrong! We''ll publish the error and then move on with
// our lives
System.out.println("Error received when indexing message: ");
t.printStackTrace();
System.out.println();
String error = PrintExc.format(t);
message.put("error", error);
if(mime == null) {
mime = "application/vnd.unknown";
}
message.put("mime", mime);
publish("IndexFailure", "", MessageProperties.PERSISTENT_BASIC, message);
}
Para completar, aquí está el método de publicación:
private void publish(String exch, String route,
AMQP.BasicProperties props, Map<String, Object> message) throws Exception{
chan.basicPublish(exch, route, props,
JSONValue.toJSONString(message).getBytes());
}
No puedo encontrar ningún código dentro del bloque try que aparezca para cerrar el canal RabbitMQ. ¿Hay alguna circunstancia en la que el canal pueda cerrarse implícitamente?
EDITAR : Debo tener en cuenta que la excepción AlreadyClosedException es lanzada por la llamada basicPublish
dentro de publish.
Me gustaría agregar esta información para otros usuarios que buscarán este tema
Otra posible razón para recibir una excepción de canal cerrado es cuando los editores y los consumidores acceden al canal / cola con diferentes configuraciones / declaraciones de cola
Editor
channel.queueDeclare("task_queue", durable, false, false, null);
Obrero
channel.queueDeclare("task_queue", false, false, false, null);
Desde el sitio RabbitMQ
RabbitMQ doesn''t allow you to redefine an existing queue with different parameters and will return an error to any program that tries to do that
Otra razón en mi caso fue que por error reconocí un mensaje dos veces. Esto dio lugar a errores de RabbitMQ en el registro como este después del segundo reconocimiento.
=ERROR REPORT==== 11-Dec-2012::09:48:29 ===
connection <0.6792.0>, channel 1 - error:
{amqp_error,precondition_failed,"unknown delivery tag 1",''basic.ack''}
Después de eliminar el acuse de recibo duplicado, los errores desaparecieron y el canal ya no se cerró y también desapareció la excepción AlreadyClosedException.
Un canal AMQP se cierra en un error de canal. Dos cosas comunes que pueden causar un error de canal:
- Intentando publicar un mensaje en un intercambio que no existe
- Intentando publicar un mensaje con el conjunto de indicadores inmediato que no tiene una cola con un conjunto de consumidores activo
Me gustaría configurar un ShutdownListener en el canal que estás tratando de usar para publicar un mensaje usando addShutdownListener() para detectar el evento shutdown y ver qué lo causó.
Yo también tuve este problema. El motivo de mi caso fue que, primero construí la cola con durable = falso y en el archivo de registro tuve este mensaje de error cuando cambié la duración a verdadero:
"arg inequivalente ''durable'' para la cola ''logsQueue'' en vhost ''/'': recibido ''true'' pero actual es ''false''"
Luego, cambié el nombre de la cola y funcionó para mí. Asumí que el servidor RabbitMQ mantiene el registro de las colas construidas en algún lugar y no puede cambiar el estado de duradero a no duradero y viceversa.
Nuevamente hice durable = falso para la nueva cola y esta vez recibí este error
"arg inequivalente ''durable'' para la cola ''logsQueue1'' en vhost ''/'': recibido ''falso'' pero actual es ''verdadero''"
Mi suposición era cierta. Cuando enumeré las colas en el servidor rabbitMQ por:
rabbitmqctl list_queues
Vi ambas colas en el servidor.
Para resumir, 2 soluciones son: 1. cambiar el nombre del nombre de la cola que no es una buena solución 2. restablecer rabbitMQ mediante:
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app