ActiveMQ: Lenteur de traitement des consommateurs

Question

En ce qui concerne ActiveMQ: J'ai un scénario dans lequel un producteur envoie de petits fichiers (environ 10 Ko) aux consommateurs. Bien que les fichiers soient petits, les consommateurs ont besoin d'environ 10 secondes pour les analyser et retourner le résultat au producteur. J'ai beaucoup recherché, mais je ne trouve toujours pas de réponses aux questions suivantes:

1. Comment faire pour que le courtier stocke les fichiers (complètement) dans une file d'attente?
2. Devrais-je utiliser ObjectMessage (car les fichiers sont petits) ou des messages blob?
3. Parce que les consommateurs sont en cours de traitement lent, devrais-je abaisser leur prefetchLimit ou utiliser une politique de répartition à la ronde? Quel est le meilleur?
4. Enfin, dans la FAQ ActiveMQ, je lis ceci: "Si un consommateur reçoit un message et ne le reconnaît pas avant de le fermer, le message sera remis à un autre consommateur.". Donc, ma question est la suivante: ActiveMQ garantit-elle qu'un seul consommateur traitera le message (et donc il n'y aura qu'une seule réponse au producteur), ou non? Quand le consommateur reconnaît-il un message (par défaut, les paramètres d'accusé de réception automatique) - lors de la réception du message et de son stockage dans une session, ou lorsque le gestionnaire onMessage est terminé? Et aussi, parce que les consommateurs sont si lents dans le traitement, devrais-je changer la "limite de délai" afin que le courtier sache combien attendre avant de donner le travail à un autre consommateur (ceci est lié à mes questions précédentes)?

Answer 1

Je ne suis pas sûr des autres, mais voici quelques réflexions.

Premièrement: je ne suis pas sûr de savoir exactement ce que vous recherchez. ActiveMQ stocke les messages dans un magasin de données; toutes les données n'ont pas besoin de rester en mémoire dans un seul endroit (courtier ou client). Donc, vous devriez être bon à cet égard; les versions antérieures nécessitaient que tous les identifiants aient besoin de rentrer dans la mémoire (pas sûr si cela était résolu), mais même cette utilisation de la mémoire serait assez faible à moins que vous n'ayez des dizaines de millions de messages dans la file d'attente.

Comme pour ObjectMessage vs blob; Le tableau d'octets bruts (blob) devrait être la représentation la plus compacte, mais puisque tous ces éléments sont sérialisés pour le stockage, cela n'affecte que l'utilisation de la mémoire sur le client. Pre-fetch aide principalement à la latence d'accès; mais étant donné qu'ils sont lents à traiter, vous n'avez probablement pas besoin d'une préextraction; alors oui, soit le mettre à 1 ou 2 ou désactiver complètement. En ce qui concerne les garanties: le mieux que les files d'attente de messages distribués peuvent garantir est soit au moins une fois (avec des doublons possibles), ou au plus une fois (pas de doublons, peut perdre des messages). Il est généralement préférable de prendre au moins une fois et de faire en sorte que les clients se dédoublent en utilisant les identifiants fournis par le client. Comment l'accusé de réception est envoyé est défini par la spécification JMS afin que vous puissiez en savoir plus sur JMS; ce n'est pas spécifique à ActiveMQ. Et oui, vous devriez régler le délai d'expiration suffisamment élevé pour que le travailleur puisse finir son travail, y compris toutes les latences réseau. Cela peut ralentir la retransmission des messages perdus (si les matrices fonctionnent), mais ce n'est probablement pas un problème pour vous.