Hello,
pour ceux qui ne lisent pas la liste anglaise, voici une copie de
l’annonce que j’ai faite tout à l’heure.
Pour ceux qui ne connaissent pas stompserver, c’est un MoM (Message
oriented Middleware), un daemon qui gère la distribution de messages à
des clients s’abonnant à des files de type FIFO ou des multicasts. Si
vous aves un besoin de traitement distribué (de longues tâches à
distribuer sur d’autres machines que vos serveurs web par exemple),
couplé avec activemessaging cela peut répondre à votre besoin.
Bonne lecture,
Lionel
stompserver version 0.9.8 has been released!
Stomp messaging server with file/dbm/memory/activerecord based FIFO
queues, queue monitoring, and basic authentication.
Changes:
0.9.8 / 16 Aug 2007
- Several storage backends instead of Madeleine (allow tradeoffs between
robustness with ActiveRecord and speed with memory with intermediary
solutions based on file or dbm storages).
- Better load distribution between clients acknowledging messages after
processing them.
- Monitoring support through a dedicated queue.
As I’m currently working on a project where I need distributed
processing, I extended Stompserver to fit my needs. This release is a
partial cleanup and enhancement of a development branch by snacktime.
There’s still some cleanup to do and the dbm backend should be
considered alpha-quality at best. But it worksforme™ and has been
distributing tens of thousands of message since its last restart without
a hitch (with the memory backend).
If you want performance and can afford message loss, use the memory
backend. If you want transactional message processing (messages are
stored in database until a client can process them and reloaded when the
server restarts), you can use the activerecord backend (configuration
details with activerecord migration in the documentation).
Happy message processing,
Lionel
PS: I can provide a Gentoo ebuild which installs an init.d script and a
default conf file on request (it’s pending more code cleanups before
submission to the distribution).
Intéressant tout ça 
Qu’est-ce que ça a de plus que Rinda?
À +
Le 16/08/07, Lionel B.[email protected] a écrit :
Le 16/08/07, Lionel B. a écrit :
Stompserver est basé sur un protocole ouvert, stomp
(http://stomp.codehaus.org/). Il est donc trivial de le remplacer par un
autre serveur comme ActiveMQ (sans changer une ligne de code, ni même la
configuration des clients Stomp). De même il est facile de développer
des clients dans d’autres langages s’il est nécessaire de s’interfacer
avec eux (pour gérer l’existant ou pour des raisons de performances par
exemple).
Donc je suppose que ActiveMessaging (
Google Code Archive - Long-term storage for Google Code Project Hosting.) peut être
utilisé vers stompserver, ce qui permettrait de basculer de manière
transparente vers Amazon SQS au cas où ? Si j’ai bien compris les MoM,
je
découvre et c’est assez impressionnant.
Frédéric Logier wrote:
avec eux (pour gérer l'existant ou pour des raisons de
performances par
exemple).
Donc je suppose que ActiveMessaging
(Google Code Archive - Long-term storage for Google Code Project Hosting.) peut
être utilisé vers stompserver,
Oui, c’est ce que je fais personnellement.
ce qui permettrait de basculer de manière transparente vers Amazon SQS
au cas où ?
Oui dans le principe, mais il y a des fonctionnalités optionnelles qui
sont accessibles en ajoutant des en-têtes spécifiques dans les messages.
Tant qu’ils ne sont pas utilisés, tu peux migrer sans soucis.
Aprèsc’est selon les fonctionnalités attachées aux en-têtes en question, mais
cela reste marginal je pense (pour Stomp, il n’y a que l’option :ack =>
‘client’ qui active les accusés de réception pour mieux garantir le
traitement des messages par exemple).
Lionel
Alexis B. wrote the following on 16.08.2007 08:15 :
Intéressant tout ça
Qu’est-ce que ça a de plus que Rinda?
Je ne connais pas bien Linda/Rinda (ça fait 9 ans que je n’ai pas touché
à Linda et ce que je faisais était très basique à l’époque…), mais il
me semble que ça n’a pas grand chose à voir (n’hésitez pas à compléter,
la suite se base sur une lecture rapide de ruby-doc.org et de
Wikipedia…)
Si je comprends bien, Linda permet des communications directes entre
processus en se basant sur un annuaire où les processus viennent s’inscrire.
Rinda est spécifique à Ruby car basé sur DRb.
Stompserver est basé sur un protocole ouvert, stomp
(http://stomp.codehaus.org/). Il est donc trivial de le remplacer par un
autre serveur comme ActiveMQ (sans changer une ligne de code, ni même la
configuration des clients Stomp). De même il est facile de développer
des clients dans d’autres langages s’il est nécessaire de s’interfacer
avec eux (pour gérer l’existant ou pour des raisons de performances par
exemple).
Les files d’attente gérées par le serveur permettent de distribuer
facilement les tâches sur plusieurs clients Stomp : il suffit de
démarrer un client supplémentaire qui se connecte à la même file
d’attente pour augmenter le nombre de traitements parallèles possibles.
Une file d’attente n’a pas besoin d’un client consommateur pour exister
: elle est créée à la première connexion d’un client producteur ou
consommateur, ce qui signifie que des demandes de traitements peuvent
être envoyées avant qu’un consommateur ait démarré (cela facilite la
gestion des phases de démarrage, seul le serveur doit être démarré en
premier et encore, activemessaging essaye de se connecter à plusieurs
reprises par exemple…).
Si le besoin est de passer une information à un ensemble de processus,
les “topics” servent à implémenter un fonctionnement multicast : tout
client Stomp attaché à un topic recevra tout message y étant
envoyé.
Côté robustesse, si un processus Rinda tombe, j’ai l’impression que tout
doit planter lorsqu’il est nécessaire (le TupleSpace tombe avec lui donc
aucune requête ne peut plus être émise si j’ai bien compris). Avec
Stomp, le serveur garde en file les demandes jusqu’à ce qu’un
consommateur soit disponible.
Lionel.
ça permet aussi d’intégrer de la messagerie instantanée à une appli
rails en utilisant xmpp4r (par exemple) ou rien à voir?
Patrick A. wrote:
ça permet aussi d’intégrer de la messagerie instantanée à une appli
rails en utilisant xmpp4r (par exemple) ou rien à voir?
En théorie, rien à voir 
Encore que si tu fais un site web qui génère un fort traffic IM, tu peux
utiliser Stompserver pour gérer une file d’attente des messages à
envoyer et avoir autant de processus envoyeurs de messages IM que
nécessaire, ce qui présente pas mal d’avantages (et quelques
inconvénients comme principalement avoir à prévoir un mécanisme de
retour asynchrone pour signaler les erreurs aux utilisateurs).
Stompserver repose sur EventMachine, ce qui lui assure de très bonnes
performances. Je n’ai pas fais de tests de charge, mais en utilisant le
backend de stockage en mémoire (celui par défaut), la seule partie
couteuse est la copie/manipulation en mémoire du message qui elle est
codée en Ruby (le reste repose sur le code C d’EventMachine qui utilise
epoll sous Linux par exemple).
Cela permet :
- d’éviter de bloquer un processus Rails lors de l’envoi du message,
- par rapport à BackgroundRB, de maîtriser l’occupation mémoire en
évitant d’avoir trop de processus BackgroundRB qui tournent (comme il
n’y a pas de file d’attente, il faut en pratique plus de processus pour
éviter de bloquer les processus Rails lors des pics de charge) et
surtout pouvoir déplacer le problème ailleurs que forcément sur la même
machine que celle ou tourne le processus Rails qui a géré la requête HTTP.
Lionel
Le 17/08/07, Lionel B. a écrit :
Cela permet :
- d’éviter de bloquer un processus Rails lors de l’envoi du message,
- par rapport à BackgroundRB, de maîtriser l’occupation mémoire en
évitant d’avoir trop de processus BackgroundRB qui tournent (comme il
n’y a pas de file d’attente, il faut en pratique plus de processus pour
éviter de bloquer les processus Rails lors des pics de charge) et
surtout pouvoir déplacer le problème ailleurs que forcément sur la même
machine que celle ou tourne le processus Rails qui a géré la requête HTTP.
Je suppose qu’on peut donc stocker un message qui est un objet sérialisé
?
Et qu’elle est la limite de taille d’un message ?
Le 17/08/07, Patrick A.[email protected] a écrit :
ça permet aussi d’intégrer de la messagerie instantanée à une appli
rails en utilisant xmpp4r (par exemple) ou rien à voir?
Si je ne me trompe pas, c’est très différent. Les MoM (et donc
StompServer pour la partie broker) sont asynchrone, donc rien
d’instantanée (ou disons c’est pas fait pour).
–
Yannick “Pouype” Francois
http://www.typouype.org
http://www.rubyfrance.org
Frédéric Logier wrote the following on 17.08.2007 15:37 :
surtout pouvoir déplacer le problème ailleurs que forcément sur la
même
machine que celle ou tourne le processus Rails qui a géré la
requête HTTP.
Je suppose qu’on peut donc stocker un message qui est un objet sérialisé ?
Oui, j’utilise YAML pour ça d’ailleurs.
Et qu’elle est la limite de taille d’un message ?
En théorie, la limite dépend du backend. Avec le backend mémoire, la
limite est ce que permet Ruby (en gros l’espace mémoire adressable et
disponible), avec celui utilisant des fichiers, la taille maximum d’un
fichier sur le système de fichier, avec activerecord, la taille maximum
d’un champs TEXT du système de gestion de base de données utilisé
(actuellement un objet est sérialisé, il faut donc compter sur
l’overhead d’un to_yaml, ceci disparaîtra dans une future version). Pour
DBM, je n’ai pas testé et je compte abandonner ce backend de toute
manière (le backend utilisant les fichiers me semble aussi robuste et
probablement plus performant).
En pratique, si tu utilises ActiveRecord par exemple, il faut compter un
temps de traitement et une occupation mémoire non négligeable pour
sérialiser les objets en base. Donc même si la limite peut être
trèsélevée (les champs TEXT supportent souvent des Go de données), le temps
de traitement peut devenir prohibitif.
Ceci dit, actuellement un message n’est sérialisé que s’il doit être mis
en attente, si un processus est disponible pour traiter le message, il
est passé sans sérialisation (je compte rendre ce comportement optionnel
pour ceux qui requièrent un maximum de robustesse).
Lionel
Salut,
Pour ceux qui ne connaissent pas stompserver, c’est un MoM (Message
oriented Middleware), un daemon qui gère la distribution de messages à
des clients s’abonnant à des files de type FIFO ou des multicasts. Si
Pour info, la quasi totalité des pages sur la doc de l’api sont en 404
http://stompserver.rubyforge.org/files/lib/stomp_server/protocols/http_rb.html
Faut attendre un rsync ?
On 8/16/07, Lionel B. [email protected] wrote:
En théorie, rien à voir
Encore que si tu fais un site web qui génère un fort traffic IM, tu peux
utiliser Stompserver pour gérer une file d’attente des messages à
envoyer et avoir autant de processus envoyeurs de messages IM que
nécessaire, ce qui présente pas mal d’avantages (et quelques
inconvénients comme principalement avoir à prévoir un mécanisme de
retour asynchrone pour signaler les erreurs aux utilisateurs).
Je suis tombé sur ça il y a pas longtemps:
http://code.google.com/p/ajaxmessaging/
ça utilise un server stomp justement même si par défaut ça a l’air
d’utiliser ActiveMQ je pense que ça peut se configurer. Si t’as 5
minutes tu peux regarder si ça marche avec ton stompserver
Mathieu C. wrote the following on 17.08.2007 17:01 :
Faut attendre un rsync ?
Je n’arrive pas à mettre à jour la doc sur le serveur actuellement
(problèmes de droits Unix sur le système de fichiers d’après la tonne de
messages d’erreur que je récupère). Le mainteneur précédent doit s’en
charger, j’attend son retour.
En attendant la seule solution est d’installer en local la gem avec la
doc.
Lionel
Au fait il manque la dépendance vers eventmachine dans le gem.
Le 16/08/07, Lionel B. a écrit :
Frédéric Logier wrote:
Donc je suppose que ActiveMessaging
(Google Code Archive - Long-term storage for Google Code Project Hosting.) peut
être utilisé vers stompserver,
Oui, c’est ce que je fais personnellement.
Bizarre j’ai quelques soucis avec lorsque je lance le poller, que ce
soit
avec stompserver que activemq :
fred@fred-laptop:~/tmp/MessageMonster$ ./script/poller run
=> Subscribing to /queue/PersistMessage (processed by
PersistMessageProcessor)
NoMethodError: You have a nil object when you didn’t expect it!
The error occurred while evaluating nil.new
/home/fred/tmp/MessageMonster/vendor/plugins/activemessaging/lib/activemessaging/gateway.rb:107:in
`connection’
/home/fred/tmp/MessageMonster/vendor/plugins/activemessaging/lib/activemessaging/gateway.rb:337:in
`subscribe’
/home/fred/tmp/MessageMonster/vendor/plugins/activemessaging/lib/activemessaging/gateway.rb:120:in
`subscribe’
/home/fred/tmp/MessageMonster/vendor/plugins/activemessaging/lib/activemessaging/gateway.rb:120:in
`each’
/home/fred/tmp/MessageMonster/vendor/plugins/activemessaging/lib/activemessaging/gateway.rb:120:in
`subscribe’
/home/fred/tmp/MessageMonster/vendor/plugins/activemessaging/lib/activemessaging/gateway.rb:24:in
`start’
/home/fred/tmp/MessageMonster/vendor/plugins/activemessaging/lib/activemessaging.rb:88:in
`start’
/home/fred/tmp/MessageMonster/vendor/plugins/activemessaging/poller.rb:14
/usr/lib/ruby/gems/1.8/gems/daemons-1.0.7/lib/daemons/application.rb:159:in
load' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.7/lib/daemons/application.rb:159:in start_load’
/usr/lib/ruby/gems/1.8/gems/daemons-1.0.7/lib/daemons/application.rb:232:in
start' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.7/lib/daemons/controller.rb:72:in run’
/usr/lib/ruby/gems/1.8/gems/daemons-1.0.7/lib/daemons.rb:136:in
run' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.7/lib/daemons/cmdline.rb:105:in call’
/usr/lib/ruby/gems/1.8/gems/daemons-1.0.7/lib/daemons/cmdline.rb:105:in
catch_exceptions' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.7/lib/daemons.rb:135:in run’
./script/poller:21
Apparemment il n’arrive pas à se connecter au serveur alors que le
fichier
de config est correct :
development:
adapter: stomp
login: “”
passcode: “”
host: localhost
port: 61613
reliable: true
reconnectDelay: 5
Frédéric Logier wrote:
`connection’
reconnectDelay: 5
A la ligne 107 de gateway.rb, le new concerne "
Gateway.adapters[config[:adapter]]".
As-tu bien installé la gem stomp ? On dirait que l’adapter que tu veux
utiliser n’est pas chargé et la cause la plus probable est que la
librairie stomp ne soit pas installée.
Lionel
Frédéric Logier wrote the following on 20.08.2007 15:56 :
Au fait il manque la dépendance vers eventmachine dans le gem.
Bien vu, je l’ajouterai à la 0.9.9
Pour info noumba.net utilise avec succès le StompServer. J’ai pu ainsi
consolider le traitement des messages et on est très satisfait.
Grand merci à Lionel pour son superbe travail !
Le 12/09/07, Lionel B. a écrit :
La majorité du code est au crédit de Patrick H., seules les
dernières évolutions sont de mon fait (bien que je les considère
essentielles, mais je ne suis pas très objectif…).
Merci à lui, sans doute un des premiers produits à utiliser StompServer
Frédéric Logier wrote:
Pour info noumba.net http://noumba.net utilise avec succès le
StompServer. J’ai pu ainsi consolider le traitement des messages et on
est très satisfait.
Grand merci à Lionel pour son superbe travail !
La majorité du code est au crédit de Patrick H., seules les
dernières évolutions sont de mon fait (bien que je les considère
essentielles, mais je ne suis pas très objectif…).
Lionel