Salut Lionel,
J’ai un problème que j’ai déjà rencontré avec des scripts ruby attaquant
une
base via AR :
err: Mysql::Error: MySQL server has gone away: INSERT INTO ar_messages
Si le script ruby n’accède pas au bout d’un certain délai à MySQL
celui-ci
ferme la connexion…
J’ai pu le résoudre en faisant simplement un require
‘mysql_retry_lost_connection’, ce gem catch l’erreur et refait la
connexion
MySQL.
Il y aurait un moyen d’intégrer cela dans le stompserver ?
Le 21/09/07, Frédéric Logier a écrit :
‘mysql_retry_lost_connection’, ce gem catch l’erreur et refait la connexion
MySQL.
Il y aurait un moyen d’intégrer cela dans le stompserver ?
Je suppose qu’un simple require ‘mysql_retry_lost_connection’ dans le
script
stompserver devrait suffire.
Frédéric Logier wrote the following on 21.09.2007 12:43 :
Le 21/09/07, Frédéric Logier a écrit :
Je suppose qu'un simple require 'mysql_retry_lost_connection' dans
le script stompserver devrait suffire.
ou plutôt dans activerecord_queue.rb
En même temps si on n’utilise pas MySQL, on n’a guère envie d’avoir à
installer cette gem…
Un require avec un rescue LoadError est envisageable, mais je croyais
qu’il était possible de configurer MySQL pour qu’il ne laisse pas les
connexions tomber ?
Lionel
Le 21/09/07, Frédéric Logier a écrit :
Je suppose qu’un simple require ‘mysql_retry_lost_connection’ dans le
script stompserver devrait suffire.
ou plutôt dans activerecord_queue.rb
Le 21/09/07, Lionel B. a écrit :
Un require avec un rescue LoadError est envisageable, mais je croyais
qu’il était possible de configurer MySQL pour qu’il ne laisse pas les
connexions tomber ?
Je ne sais pas si c’est une bonne idée.
Frédéric Logier wrote the following on 21.09.2007 16:28 :
Le 21/09/07, Lionel B. a écrit :
Un require avec un rescue LoadError est envisageable, mais je croyais
qu'il était possible de configurer MySQL pour qu'il ne laisse pas les
connexions tomber ?
Je ne sais pas si c’est une bonne idée.
Dans ce cas, je vais attendre que quelqu’un m’explique les désavantages
avec MySQL :
- à ma connaissance seul MySQL présente ce comportement,
- cela ressemble beaucoup à une protection contre un bug qui ferait que
soit :
. un client SQL oublierait de se déconnecter (et dans ce cas ils
solutionnent le problème au mauvais endroit, je ne vais pas les suivre
sur ce terrain),
. le serveur oublie de fermer les connexions proprement (même remarque).
Si toutes les versions de MySQL ont des problèmes si on ne laisse pas le
serveur fermer les connexions inactives, je veux bien reconsidérer ma
position pour que les utilisateurs aient une solution (sinon, la
solution est de mettre à jour MySQL). J’ai l’habitude, ce n’est pas la
première fois que je dois adapter un soft pour contourner les
limitations de MySQL…
Lionel
Le 22/09/07, Lionel B. a écrit :
Si toutes les versions de MySQL ont des problèmes si on ne laisse pas le
serveur fermer les connexions inactives, je veux bien reconsidérer ma
position pour que les utilisateurs aient une solution (sinon, la
solution est de mettre à jour MySQL). J’ai l’habitude, ce n’est pas la
première fois que je dois adapter un soft pour contourner les
limitations de MySQL…
Je suis entièrement d’accord avec toi, personnellement je suis
complètement
fan d’un vrai SGBD tel que PostgreSQL. Cependant ce n’est
malheureusement
pas moi qui est en position de décider 
Ma question n’était pas que tu adaptes StompServer à MySQL, mais comment
moi
je peux l’adapter pour résoudre ce problème de MySQL
(sans doute en
incluant le gem mysql_retry_lost_connection dans activerecord_queue.rb).
Frédéric Logier wrote:
solutionnent le problème au mauvais endroit, je ne vais pas les suivre
limitations de MySQL...
Je suis entièrement d’accord avec toi, personnellement je suis
complètement fan d’un vrai SGBD tel que PostgreSQL. Cependant ce n’est
malheureusement pas moi qui est en position de décider 
Ma question n’était pas que tu adaptes StompServer à MySQL, mais
comment moi je peux l’adapter pour résoudre ce problème de MySQL 
(sans doute en incluant le gem mysql_retry_lost_connection dans
activerecord_queue.rb).
Je ne connais pas le “mysql_retry_lost_connection”, mais il doit
certainement modifier soit establish_connexion (il me semble qu’il y a
un paramètre à passer qui permet la reconnection auto), soit execute (en
implémentant un réessai lorsqu’on lève l’exception correspondant à la
perte de connection par exemple).
Donc pour être sur que ça fonctionne il faut le charger avant
l’établissement de la connection, un require au début
d’activerecord_queue.rb me semble idéal.
Lionel
Frédéric Logier wrote the following on 20.08.2007 21:50 :
Oups en effet désolé. Il faudrait ajouter la dépendance stom à
stomserver aussi 
stompserver ne dépend pas de la librairie stomp (l’interprétation des
messages stomp tient dans deux classes qui totalisent 96 lignes…).
Ce qui serait bien c’est qu’activemessaging soit livré comme gem, ce qui
permettrait de gérer les dépendances là où c’est nécessaire (mais il
faut reconnaître que leur doc d’install est assez exhaustive).
Lionel
Le 22/09/07, Lionel B. a écrit :
Je ne connais pas le “mysql_retry_lost_connection”, mais il doit
certainement modifier soit establish_connexion (il me semble qu’il y a
un paramètre à passer qui permet la reconnection auto), soit execute (en
implémentant un réessai lorsqu’on lève l’exception correspondant à la
perte de connection par exemple).
A la class MysqlAdapter de AR il fait dans le rescue
ActiveRecord::StatementInvalid => exception
un reconnect si la connexion a été perdue.
Donc pour être sur que ça fonctionne il faut le charger avant
l’établissement de la connection, un require au début
d’activerecord_queue.rb me semble idéal.
Merci beaucoup pour ton aide.
Le 20/08/07, Lionel B. a écrit :
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.
Oups en effet désolé. Il faudrait ajouter la dépendance stom Ã
stomserver
aussi 