J'utilise Activemq comme courtier pour livrer des messages. Ces messages sont inventés d'être écrits dans une dabatase. Parfois, la base de données est inaccessible ou basse. Dans ce cas, je souhaite retourner mon message pour réessayer plus tard ce message et je veux continuer à lire d'autres messages.
Ce code fonctionne bien, sauf un point: le message renommé me bloque de lire les autres: P >
commit 1 rollback 2 commit 3 commit 4 wait 5s rollback 2 wait 5s rollback 2 wait 5s put 2 in dead letter queue (ActiveMQ.DLQ)
3 Réponses :
Utilisez-vous le Dans le fichier de configuration de l'activemq XML? Je ne sais pas si cela affectera l'ordre des messages pour la livraison ou non. Si vous utilisez une expédition de commande stricte, essayez de commenter cette politique pour voir si cela change le comportement.
Bruce
Non, je n'utilise pas cette politique. Merci pour le lien.
Ceci est en réalité attendu Comportement, car les tentatives de message sont traitées par le client, pas le courtier. Donc, comme vous avez 1 session Bound, et votre stratégie de réessaye est configurée pour les 3 tentatives avant la DLQ, l'ensemble du processus de tentative bloque le thread particulier.
Donc, ma première question est que si l'insertion de la base de données échoue, ne vous attendez-vous pas à tout le reste de vos inserts de DB échouer pour une raison similaire?
Si ce n'est pas le cas, le moyen de contourner la stratégie de réessaye pour que cette file d'attente soit 0 tentative, avec une DLQ spécifique, de sorte que les messages échouent immédiatement et entrent dans la DLQ. Ensuite, disposez d'un autre processus qui retire la DLQ toutes les 5 secondes et les retraites et / ou le remet dans la file d'attente principale pour le traitement.
Merci pour l'explication claire du comportement. Nous avons enfin choisi Rabbitmq comme un courtier et avons mis en œuvre la DLQ par nous-mêmes.
J'ai eu le même problème, je n'ai pas trouvé de solution ici, alors a décidé de la publier ici après avoir trouvé un pour les personnes qui ont du mal à la même chose. Ceci est corrigé avant la version 5.6 Lorsque vous définissez la propriété NOBLOCKINGERELIVERY sur TRUE en Connexion Factory:
<property name="nonBlockingRedelivery" value="true" />