ActiveMQ: Comment gérer courtier basculements tout en utilisant des files d'attente temporaires

Question

Sur mon JMS applications que nous utilisons files d'attente temporaires sur les Producteurs pour être en mesure de recevoir les réponses à partir des demandes des Consommateurs.

Je suis confronté exactement le même problème sur ma fin, comme mentionné dans ce fil: http://activemq.2283324.n4.nabble.com/jira-Created-AMQ-3336-Temporary-Destination-errors-on-H-A-failover-in-broker-network-with-Failover-tt-td3551034.html#a3612738

Chaque fois que j'ai redémarré l'arbitraire d'un courtier dans mon réseau, j'ai été faire beaucoup d'erreurs de ce genre dans mon application Consommateur de journal, tout en essayant d'envoyer la réponse à une file d'attente temporaire:

javax.jms.InvalidDestinationException:
  Cannot publish to a deleted Destination: temp-queue://ID:...

Puis j'ai vu Gary réponse ce qui suggère d'utiliser

jms.watchTopicAdvisories=false

comme un param url sur le client brokerURL. J'ai rapidement changé mon client courtier Url avec ce paramètre supplémentaire. Mais maintenant, je vois des erreurs de ce genre quand j'ai redémarrer mon courtiers en réseau pour ce test de basculement:

javax.jms.JMSException: 
  The destination temp-queue:
    //ID:client.host-65070-1308610734958-2:1:1 does not exist.

Je suis à l'aide de ActiveMQ version 5.5. Et mon client courtier URL ressemble à ceci:

failover:(tcp://amq-host1:61616,tcp://amq-host2.tred.aol.com:61616,tcp://amq-host3:61616,tcp://amq-host4:61616)?jms.useAsyncSend=true&timeout=5000&jms.watchTopicAdvisories=false

En outre, voici mon activemq config XML pour l'une des 4 courtiers: amq1.xml

Quelqu'un peut ici s'il vous plaît examiner ce problème et de me suggérer ce que l'erreur que j'ai fais dans cette configuration.

Mise à jour:

Pour clarifier davantage sur la façon dont je suis en train de faire de requête-réponse dans mon code:

1. J'ai déjà utiliser par un producteur de destination (c'est à dire temporaire d'attente) et dans la réponse de l'en-tête de chaque message.
2. Je suis en train d'envoyer un message par unique identificateur de corrélation dans JMSCorrelationID en-tête.
3. Autant que je sache, même Chameau et le Printemps sont également à l'aide temporaire d'attente pour demande de mécanisme de réaction. La seule différence est que le Printemps JMS mise en œuvre crée et détruit temporaire de la file d'attente pour chaque message alors que j'ai créer file d'attente temporaire pour la durée de vie du producteur. Cette file d'attente temporaire est détruit lorsque le client (producteur) app shutsdown ou par l'AMQ courtier lorsqu'il se rend compte qu'il n'est actif producteur attaché à cette file d'attente temporaire.
4. Je suis déjà un message d'expiration de chaque message sur le Producteur de côté afin que le message ne soit pas bloqué dans une file d'attente trop long (60 sec).

Answer 1

Il y a un courtier d'attribut, org.apache.activemq.courtier.BrokerService#cacheTempDestinations qui devraient vous aider dans le basculement: cas. Jeu de vrai dans de configuration xml, et un temp de destination ne sera pas supprimé immédiatement lorsqu'un client se déconnecte. Un basculement rapide: reconnecter sera en mesure de producteur et/ou de consommer de la temp file d'attente à nouveau.

Il y a un timer tâche basée sur timeBeforePurgeTempDestinations (par défaut 5 secondes) qui gère la suppression de cache.

Un bémol cependant, je ne vois pas de tests dans activemq-core qui rendent l'utilisation de cet attribut, donc je ne peux vous donner aucune garantie sur ce point.

Answer 2

Files d'attente temporaires sont créés sur le courtier à qui le demandeur (producteur) dans votre demande de réponse scénario se connecte. Ils sont créés à partir d'un javax.jms.Session, sur cette déconnexion de session, soit en raison de la déconnexion du client ou d'un courtier d'échec/de basculement, ces files d'attente sont définitivement disparu. Aucun des autres courtiers vous de comprendre ce que l'on entend lorsque l'un de vos consommateurs tente de répondre à ces files d'attente; par conséquent, votre exception.

Cela nécessite une architecture changement de mentalité en supposant que vous voulez traiter avec basculement et persistent à tous vos messages. Voici une façon générale que vous pourriez attaquer le problème:

1. Votre réponse-d'en-têtes doivent se référer à une file d'attente spécifique pour le demandeur de processus: par exemple, queue:response.<client id>. L'id du client pourrait être un nom standard si vous avez un nombre limité de clients ou d'un UUID si vous avez un grand nombre de ces.
2. Le message sortant est recommandé de définir un identificateur de corrélation (il suffit d'un aiguillon qui permet d'associer une demande avec une réponse, les demandeurs après tout peut faire plus d'une demande dans le même temps). Ce paramètre est défini dans l' JMSCorrelationID - tête, et de ce qui doit être copié à partir de la demande pour le message de réponse.
3. Le demandeur doit mettre en place un listener sur la file d'attente qui sera de retour le corps du message à la demande de filetage selon que correllation id. Il y a quelques multithreading code qui doit être écrite pour ce faire, car vous aurez besoin de gérer manuellement quelque chose comme une carte de corrélation id originaires de threads (via des contrats à Terme peut-être).

C'est une approche similaire à celle prise par Apache Camel pour la requête-réponse sur la messagerie.

Une chose d'être conscient de, c'est que la file d'attente ne va pas disparaître lorsque le client, de sorte que vous devez définir un temps pour vivre sur le message de réponse tel qu'il est supprimé à partir du courtier si elle n'a pas été consommé, sinon vous obtiendrez un carnet de commandes de messages non consommées. Vous aurez également besoin de mettre en place une file d'attente de lettres mortes stratégie visant à supprimer systématiquement les messages périmés.