El cliente usa STOMP versión 1.2 sobre RabbitMQ versión 3.9.3.
El cliente se usa para una aplicación de chat como suscriptor para los mensajes entrantes.
a["CONNECTED\nserver:RabbitMQ/3.9.3\nsession:session-paGrRWWiEsYECaWdVdqkXQ\nheart-beat:4000,4000\nversion:1.2\nuser-name:6208370595c29c4357f9b81c\n\n\u0000"] El encabezado de ack de recibo en la suscripción es client-individual .
El cliente puede acknowledge un mensaje sin excepciones de RabbitMQ.
El problema es que, cuando el cliente no acknowledge , el mensaje no se vuelve a enviar al cliente.
Quiero que se vuelva a enviar el mensaje al suscriptor si el suscriptor no acknowledged el mensaje.
¿Es posible crear una función de este tipo utilizando las soluciones integradas de STOMP y RabbitMQ, sin hacer ningún reconocimiento personalizado?
La peor solución alternativa que probé fue que configuré consumer_timeout to 10000 en rabbitmq.conf , lo que debería desconectar a un suscriptor que no recibe un mensaje durante 10 segundos, luego el cliente se vuelve a conectar al cliente y recupera el mensaje perdido. El problema con esta solución es que se tarda 1 minuto, no 10 segundos, en desconectar a un suscriptor después de no enviar el acuse de recibo.
El corredor de mensajes decide cómo se manejan los mensajes nack, en su caso RabbitMq. Se pueden descartar, enviar a una cola de mensajes fallidos o volver a poner en cola.
Los documentos te ayudarán: https://www.rabbitmq.com/nack.html
Para utilizar el mecanismo de puesta en cola, debe utilizar basic.reject o basic.nack en caso de volumen. La forma en que lo configure depende de la API de la biblioteca del cliente que use.
Consulte también: https://www.rabbitmq.com/confirms.html#consumer-nacks-requeue
A veces, un consumidor no puede procesar una entrega de inmediato, pero otras instancias podrían hacerlo. En este caso se puede desear volver a ponerlo en cola y dejar que otro consumidor lo reciba y manipule. basic.reject y basic.nack son dos métodos de protocolo que se usan para eso.
Los métodos se utilizan generalmente para confirmar negativamente una entrega. Tales entregas pueden ser descartadas por el intermediario o puestas en cola. Este comportamiento está controlado por el campo Requeue. Cuando el campo se establece en verdadero, el intermediario volverá a poner en cola la entrega (o varias entregas, como se explicará en breve) con la etiqueta de entrega especificada.
Bueno... hay mucho que discutir sobre qué configuración elegir al usar rabbitmq . Recomendaré la siguiente configuración (para empezar)
Use el modelo fanout (como se describe en los documentos ). Esto le permitirá:
En resumen: sí, hay una configuración que se adapta a sus necesidades En profundidad: debe diseñar cuidadosamente su configuración para satisfacer todas sus necesidades (incluida la alta disponibilidad) para garantizar que su código y su implementación se mantengan a medida que avanza su proyecto