Evénement de réception de message ActiveMQ uniquement un message par seconde?

Question

Nous avons construit une infrastructure d'application basée sur ActiveMQ.

Nous pouvons envoyer et recevoir des messages très bien, et pour la plupart, les choses sont plutôt rapides et correctes. Cependant, nous avons remarqué que si nous soumettons un lot de messages "à la fois", disons 5 000 messages - qu'ActiveMQ enverra les messages à l'application tierce à l'autre extrémité assez rapidement, et que cette application processus aussi assez rapidement, et qu'il fera en queue les réponses au courtier rapidement aussi, disons moins d'une minute. Mais pour une raison quelconque, notre EXE VB.NET qui a généré les messages ne semble traiter que les messages de retour qu'il reçoit de manière erratique, en faisant parfois environ une par seconde, en prenant parfois des pauses pendant une heure ou deux. puis revenant à un par seconde.

Origin (VB.NET EXE which we manage) 
    -> Broker (which we manage) 
     -> (3rd party app) 
      -> back to the same broker 
       -> back to the origin app. 

Le récepteur attend le MessageListener de l'événement à partir du code C# téléchargé à partir ActiveMQ il y a peut-être 9 mois:

Public Delegate Sub MessageListener(ByVal message As NMS.IMessage) 
    Member of: NMS 

Je pense que ce qui se passe est que MessageListener ne nous donne un message (NMS.IMessage) à mâcher, et c'est ce que nous traitons. Y at-il un moyen de dire "Sur un événement MessageListener, s'il vous plaît voir s'il y a d'autres messages dans la file d'attente en ce moment et les faire tous"?

Answer 1

Turns dehors, nous pensons que nous savons un peu plus maintenant de quoi il s'agit. Lorsque notre application VB.NET WinForms qui utilise la DLL ActiveMQ finit par se bloquer, ce qu'elle a tendance à faire quelques fois par semaine, nous avons un programme de surveillance qui utilise les utilitaires pslist et pskill de Winternals pour récolter le zombie, puis démarrer une nouvelle connexion client. Dans ce cas, l'utilisation de jconsole pour analyser le courtier nous montre que la session du zombie est toujours enregistrée, tout comme le nouveau client. Ma théorie en ce moment est que quand AMQ voit les deux sessions, il essaye de commencer à distribuer des messages aux deux sessions round-robin style. AMQ essaie d'envoyer le message au zombie, qui ne répond pas. Après un certain temps (une seconde peut-être), l'AMQ abandonne et passe à la prochaine session de la liste, le nouveau client. À un certain point, le courtier ou la pile TCP remarque probablement que le zombie n'a pas gardé sa connexion TCP active et il abandonne; alors le fonctionnement revient à la normale. Donc, la question devient, comment écrire un client ActiveMQ qui a) ne meurt pas ou b) meurt gracieusement, en arrêtant sa session dans le processus?

Modifier: la mise à niveau vers la prochaine version d'ActiveMQ a permis de résoudre ce problème. Nous avions aussi une seule application qui faisait l'envoi et la réception, mais ce n'était pas threadsafe - donc si elle a reçu pendant qu'elle essayait d'envoyer ceci a causé les accidents. Nous l'avons réécrit comme deux applications de console, une qui a envoyé des données et une qui a reçu des données. Plus d'accidents. De plus, l'ancienne version d'ActiveMQ que nous utilisions à ce moment-là ne gérait pas correctement les plantages, la mise à niveau vers la version 4.x a résolu ce problème.

Answer 2

Je vous suggère d'avoir signalé ce au User Forum ainsi soulever peut-être un support issue que cela ressemble à ce pourrait être une question avec le code client NMS et tous les NMS développeurs sont sur cette liste et pourrait répondre