¿Qué sucede si un mensaje se revierte en MQ?

Question

Recibo un mensaje de una cola de WebSPhere MQ. Intento procesar y, si recibo algunas excepciones, quiero retrotraer el mensaje a la cola de MQ.

No tengo problemas para hacer lo mismo. ¿Qué pasa con el mensaje? ¿Va al final de la cola?

Si intento sacar un mensaje de la cola, ¿recibiré el mismo mensaje que repliqué?

¿Cuál es el comportamiento probable? Quiero saber este comportamiento normalmente en un escenario de cola de alto volumen?

Apreciar cualquier entrada.

Gracias, Manglu

Answer 1

Si usted está haciendo operaciones de la cola en el marco de una transacción, y una reversión se produce, a continuación, después de la transacción se resuelve la cola y el mensaje aparecerá tal como lo hizo antes de que comenzara la operación. En otras palabras, no hay cambios en absoluto.

En un escenario de alto volumen, sin embargo, es típico tener múltiples lectores y escritores transaccionales en una sola cola, y no bloquean la cola completa para cada cola o en cola.

Estos lectores y escritores insertarán elementos en la cola, o quitarán los elementos de la cola de manera transaccional, mientras se resuelve su transacción perdida. En ese caso, otros elementos de cola pueden aparecer o desaparecer (o ambos).

Si después de la reversión de la transacción original, dequeue nuevamente de la cola, puede obtener el mensaje original, pero no es posible. En un escenario de alto concurrencia de alto volumen, es posible que otro lector haya retirado el mensaje antes de que su código pueda hacerlo.

Answer 2

Rollback deja el mensaje en la cola y lo pone para volver a entregarlo.

Sin embargo, cuando se alcanza un límite (configurable) de intentos de reenvío, el mensaje se deja de lado en la "cola de mensajes no entregados".

Un ejemplo típico donde esto sucede es s.c. 'mensajes venenosos': mensajes que no se pueden tratar debido a problemas fundamentales y no transitorios (como un formato no válido, campos faltantes, etc.).

Así que antes de deshacer (y poner el mensaje de nuevo en la cola), asegúrese de pensar si el error es transitorio (como si las conexiones con el servidor se rompieran) o no.

En este último caso, es mejor tragarse el mensaje y registrar un error o disparar alguna otra alerta. De lo contrario, el mensaje consumirá innecesariamente la potencia de procesamiento y la infraestructura de la cola.

HTH

individuo

Answer 3

Para responder a un par de los puntos específicos de este hilo ...

• El mensaje conserva su posición en la cola. El OBTENER en punto de sincronización bloquea el mensaje, pero no lo elimina de la cola ni cambia su posición. Rollback libera el bloqueo y hace que el mensaje esté disponible para su entrega.
• La recarga automática de un mensaje venenoso ocurre con las clases JMS y XMS pero no con las API nativas de Java, C, C#, COBOL, etc. Si no está utilizando JMS o XMS (que implementa la API de JMS para los programas C y .Net), deberá volver a poner el mensaje en la cola.
• Tiene la razón de que se intentará reabastecer en la cola nombrada en el atributo BOQNAME de la cola de entrada después de exceder las entregas BOQTHRESH. Si esa cola no está disponible (completa, no autorizada, inexistente, etc.) entonces se intenta el DLQ. Si eso falla, el oyente del mensaje deja de recibir mensajes por completo.
• Lo ideal es que un programa maneje un mensaje de envenenamiento al volver a colocarlo en una pila y alertar sobre la presencia de mensajes en la cola de excepciones. De lo contrario, al menos no solo consuma y descarte el mensaje. Regístrese, junto con los encabezados de los mensajes, para que alguien más tarde pueda reconciliar lo que le sucedió.