Stompserver et Prefetch limit?

Community FR
1

Bonjour,

Existe-t’il un équivalent à la prefetch limit d’activeMQ avec
stompserver ?

“Its a good idea to have large values of the prefetch limit if you want
high performance and if you have high message volumes. If you have very
few messages and each message takes a very long time to process you
might want to set the prefetch value to 1 so that a consumer is given
one message at a time. Specifying a prefetch limit of zero means the
consumer will poll for more messages, one at a time, instead of the
message being pushed to the
consumer.”
(ActiveMQ)

Par exemple, avec activemessaging/ActiveMQ, j’envoi dans mon message le
paramètre activemq.prefetchSize: 1 pour régler cette limitation.

Merci pour vos réponses,

Jérémy.

2

Bonjour,

Peut être mon message est-il tombé dans les oubliettes du mois d’août :

Le lundi 10 août 2009 à 11:38 +0200, JD a écrit :

of zero means the consumer will poll for more messages, one at a time,
instead of the message being pushed to the
consumer." (ActiveMQ)

Par exemple, avec activemessaging/ActiveMQ, j’envoi dans mon message
le paramètre activemq.prefetchSize: 1 pour régler cette limitation.

Merci pour votre aide.

J.

3

JD a écrit, le 09/08/2009 04:33 PM :

le paramètre activemq.prefetchSize: 1 pour régler cette limitation.

Merci pour votre aide.

Les détails de prefetch limit m’échappent, mais dans ce qui me semble
être la même veine, Stompserver distribue tous les messages aux clients
sans attendre de ack. Ce comportement est modifié lorsqu’un client
s’inscrit avec :ack => ‘client’. Dans ce dernier cas Stompserver attend
un accusé de réception du client avant de passer au message suivant.

Lionel

4

JD a écrit :

le paramètre activemq.prefetchSize: 1 pour régler cette limitation.

Merci pour votre aide.

J.

Moi j’utilise nanite \o/

–
Cyril M.

5

2009/9/8 Cyril M. [email protected]

Existe-t’il un équivalent à la prefetch limit d’activeMQ avec
ActiveMQ)

Moi j’utilise nanite \o/

+1

Dans ton cas, tu peux tirer profit des options de nanite lors de l’envoi
d’un message :

  • selection du noeud de traitement : moins chargé, tous, random
  • push ou call

Je pense que ca pourrait t’aider et rabbitMQ est a mon avis plus
scalable
que stompserver.

–
http://fabien.jakimowicz.com
Sent from Cachan, France

6

JD a écrit, le 09/09/2009 10:45 AM :

l’attente ack, le processeur dirige l’exécution de ce second message
vers le 2eme poller qui à son tour ne renverra un ack qu’à la fin du
traitement.
Le même scénario se produit pour le 3eme poller et tous les pollers sont
ainsi occupés.
Si un 4eme message arrive avant que l’un des pollers soit à nouveau
disponible, le message est perdu,

?

C’est plus qu’étonnant. Le rôle d’un gestionnaire de file d’attente,
c’est quand même de gérer l’attente des messages ne pouvant être traités
immédiatement.
Je n’ai jamais rencontré ce problème avec Stompserver (et pourtant j’ai
des files d’attente de plusieurs centaines voir milliers d’entrées et
des tests en live vérifiant que tous les traitements sont bien réalisés
en temps fini).

le processeur renvoyant simplement un
message d’erreur au broker.

Quel message ?

Lionel

7

Merci pour vos réponses,

Le mardi 08 septembre 2009 à 17:02 +0200, Lionel B. a écrit :

Les détails de prefetch limit m’échappent, mais dans ce qui me semble
être la même veine, Stompserver distribue tous les messages aux clients
sans attendre de ack. Ce comportement est modifié lorsqu’un client
s’inscrit avec :ack => ‘client’. Dans ce dernier cas Stompserver attend
un accusé de réception du client avant de passer au message suivant.

Voici un exemple pour vous permettre de comprendre mon besoin (constat
issu de tests précédemment effectués) :

J’ai un processeur activemessaging avec 3 pollers inscrits avec
acquittement client (:ack => ‘client’).
Ces pollers exécutent des tâches longues (plusieurs minutes voir
plusieurs heures).
Un premier message arrive et son exécution monopolise l’un des pollers
qui ne renverra son ack au broker qu’a la fin du traitement.
Le 1ere poller étant occupé, un second message arrive. Du fait de
l’attente ack, le processeur dirige l’exécution de ce second message
vers le 2eme poller qui à son tour ne renverra un ack qu’à la fin du
traitement.
Le même scénario se produit pour le 3eme poller et tous les pollers sont
ainsi occupés.
Si un 4eme message arrive avant que l’un des pollers soit à nouveau
disponible, le message est perdu, le processeur renvoyant simplement un
message d’erreur au broker.
La solution serait il me semble de limiter le nombre de message Ã
destination du processeur (prefetch limit), soit 3 dans le cas présent,
correspondant au nombre de pollers du processeur.
Dans ce cas, si un 4eme message arrive au broker (celui-ci ayant
comptabilisé le nombre de messages précédemment envoyés au processeur)
attend simplement que l’un des pollers du processeur ce libère. Aucun
message n’est perdu.
La prefetch limit complète l’utilisation de l’ack ‘client’.

Pour plus d’info sur la prefetch limit d’activeMQ :

http://activemq.apache.org/what-is-the-prefetch-limit-for.html

Pour le moment, je comptabilise les tâches en cours d’execution par mes
pollers dans la db avec une limite haute fixée au nombre de pollers.

Le mardi 08 septembre 2009 à 17:26 +0200, Cyril M. a écrit :

Moi j’utilise nanite \o/

je vais regarder nanite de plus près.

Cdt,

Jérémy.

8

Le mercredi 09 septembre 2009 à 10:55 +0200, Lionel B. a écrit :

Quel message ?

Je n’ai plus le message. Je vais remettre en place les tests effectués
début août. Je fais un retour dès que j’ai les résultats. Peut-être une
mauvaise interprétation de ma part ?

J.