Limitation dynamique d'une file de messages ActiveMQ avec Camel

Question

Je suis un membre de la communauté ActiveMQ / Camel ayant à l’esprit un scénario en particulier. Je me demande tout d’abord s’il est possible et deuxièmement que l’on puisse donner un peu d’information.

En principe, je dois effectuer une limitation dynamique de la file d'attente. C'est-à-dire la possibilité de définir au moment de l'exécution le débit qu'un groupe particulier de messages sera consommé à partir de la file d'attente.

Ainsi, je pourrais par exemple ajouter un groupe de messages devant être consommés à 10 par seconde, un autre groupe devant être consommé à 1 par seconde, etc.

.

Je connais les bases de la configuration des itinéraires dans Camel et du groupement de messages dans la file d'attente, etc., mais je ne peux tout simplement pas le comprendre à l'aide de la documentation.

Answer 1

Oui, il semblerait que vous recherchiez une limitation du côté des courtiers afin d'éviter que les consommateurs ne se bloquent.

Avez-vous formulé votre demande sur le forum utilisateur / dev d'ActiveMQ?

Answer 2

Vous pouvez simplement utiliser le throttler existant dans Camel, puis utiliser une file d'attente différente pour chaque type. des messages pour lesquels vous devez configurer un taux d’accélération différent?

par exemple

from("activemq:Queue1.Input").
    throttle(20).
    to("activemq:Queue1.Output");  
from("activemq:Queue2.Input").
    throttle(5).
    to("activemq:Queue2.Output");  

Answer 3

Pourquoi n'ajoutez-vous pas un RFE dans Apache Camel JIRA?

Quelle est votre logique pour déterminer le débit d'un groupe de messages donné?

Si différents groupes de messages passent dans le même throttler, cela peut devenir complexe. Un discriminateur est nécessaire pour déterminer le message auquel le groupe appartient et, par conséquent, le taux auquel le throttler doit être transmis.

Si vous prenez le temps de remplir votre cas d'utilisation et de consigner le RFE, je suis sûr que la communauté Camel, les développeurs peuvent vous aider.

Vous pouvez essayer de le mettre en œuvre vous-même. Fondamentalement, tout ce qui est processeur est un processeur, vous pouvez donc faire un processus à partir de ("activemq: queue: foo"). Process (myOwnThrottler) .to ("bean: handleMessage");

Vous pouvez étendre certaines classes de Camel: - DelegateProcessor - DelayProcessorSupport - étrangleur

Claus Ibsen Apache Camel Committer

Intégration Open Source: http://fusesource.com Blog: http://davsclaus.blogspot.com/

Answer 4

OK, je vais décrire le scénario un peu plus en détail et mettre en évidence le bloqueur principal, autant que je sache.

J'ai 2 groupes de messages (en réalité, l'échelle est beaucoup plus grande), chacun avec une exigence de limitation différente. Disons que je le spécifie dans l'en-tête du message en tant que flowRate et flowTime.

• Groupe 1: FlowRate = 1; flowTime = 60 (1 par minute)
• Groupe 2: FlowRate = 1; flowTime = 1 (1 par seconde)

J'implémente un processeur conforme aux Claus , qui examine les champs d'en-tête et les utilise comme entrée de suppression.

J'ajoute 20000 messages du groupe 1 et 20000 du groupe 2

Etant donné que le throttler est du côté consommateur, le convertisseur activé par le groupe 1 ralentira son remplissage en remplissant rapidement son tampon d’entrée et les messages du groupe 2 resteront bloqués ... même si j’utilise plusieurs files d’attente, comme indiqué dans James .

Je réalise que je peux grouper le message à l'aide de l'en-tête JMXGroupID et implémenter plusieurs consommateurs, mais je ne pense pas que cela répondrait à la nécessité de prendre en charge les n groupes.

Ce que je me demandais, en gros, c’est s’il existe un moyen de faire de la courtier plutôt que de limiter le consommateur, ou une autre solution permettant au consommateur de contrôler sans finalement bloquer.

J'espère m'être expliqué clairement et merci pour les suggestions formulées jusqu'à présent.