ActiveMq, que se passe-t-il si le client se termine avant Ack

Question

J'ai une file d'attente persistante, non négociée, avec accusé de réception par le client, les consommateurs lisent avec jms.prefetchPolicy.queuePrefetch=1&wireFormat.maxInactivityDuration=50000.

et une fois qu'un consommateur traite un message, il accuse réception du message.

Si le consommateur lit le message, et avant qu'il puisse envoyer un ack, le processus se termine brusquement, que se passe-t-il dans ActiveMq ? (Quels paramètres ActiveMq entrent en jeu ici ?)

Quelle est la différence avec le cas où le consommateur prend 10 minutes pour traiter le message (donc la tâche du consommateur est vivante et fonctionne), comment ActiveMq sait-il que le message est toujours en cours de traitement ? (Est-ce qu'il surveille la connexion TCP/IP, si la connexion meurt, il suppose que le message ne sera pas Ack'ed) ?

Comment puis-je déterminer si un message est une "pilule empoisonnée", c'est-à-dire s'il fait planter les consommateurs (le compte de re-livraison semble être valide si la tâche du consommateur ne meurt pas ; y a-t-il un compteur interne dans le message qui dit "il a été lu n fois sans être ack'ed avec succès" ?)

A titre expérimental, j'ai envoyé 6 messages, l'un d'entre eux étant une "pilule empoisonnée" (tue le consommateur avant qu'il ne puisse envoyer l'ack), avec 2 consommateurs simultanés en cours d'exécution (et redémarrant automatiquement les consommateurs pour ramener le nombre à 2 chaque fois qu'un consommateur meurt). En regardant la file d'attente (en utilisant jconsole, j'active jmx en utilisant broker.setUseJmx(true)), 4 messages ont été délivrés, 2 sont en vol. Pourquoi y aurait-il 2 messages en vol au lieu d'un seul ?

J'ai lu les spécifications d'ActiveMq et de JMS pendant un certain temps sans obtenir de réponses claires/concluantes, donc toute idée sur les paramètres qui entrent en jeu, et s'il y a des bogues connus, sera très utile.

Answer 1

Ceci est purement basé sur ma compréhension de JMS - peut ne pas être complètement correct :

Si le consommateur lit le message, et avant qu'il puisse envoyer un ack, le processus se termine brusquement, que se passe-t-il dans ActiveMq ?

Si j'ai bien compris, puisque cela se produit dans le contexte d'une session avec le fournisseur JMS, ce dernier sait si la session n'est plus active ou a échoué et tout message qui n'a pas fait l'objet d'un accusé de réception dans le cadre de la session sera redélivré lorsque la session sera rétablie.

Comment déterminer si un message est une "pilule empoisonnée", c'est-à-dire qu'il fait planter les consommateurs ?

Comme vous l'avez mentionné, le fournisseur JMS garde la trace du nombre de fois où le message a été réacheminé, éventuellement dans l'en-tête du message.

4 messages ont été délivrés, 2 sont en vol

Je ne suis pas sûr de ce point