search

SysFera / vishnu

Modular and high-level middleware for tasks, files and information management in heterogeneous and distributed HPC environments
http://sysfera.github.com/vishnu.html
Other
4 stars 12 forks source link

vishnu_ls en erreur pour ivanoe (Bugzilla #459) #312

Closed bdepardo closed 11 years ago

bdepardo commented 11 years ago

critical bug in component TMS Reported in version 2.0.0 beta1 on platform Other

bdepardo commented 11 years ago

On 2013-02-14 10:23:54 +0100, 'Samuel Kortas (samuel.kortas@edf.fr) wrote: un vishnu_ls ivanoe:.

renvoie

vishnu_ls: Vishnu not available (Data error) [Error by receiving List object serialized]

avec sur le dispatcher avec un timeout de 50 C a trace d'erreur au niveau du dispatcher. W: no response from tcp://:5556, retrying ...
W: no response from tcp:/:5556, retrying ...
E: server seems offline, abandonning E: request failed, exiting ...

Il n'y a pas un timeout a mettre sur fms?

SK

bdepardo commented 11 years ago

On 2013-02-14 10:35:49 +0100, 'Kevin Coulomb (kevin.coulomb@sysfera.com) wrote: La problématique est similaire au bug 358, le dispatcher n'a pas de réponse et le timeout est à chaque fois atteint ce qui fait que l'on se retrouve avec des données invalides coté client après.

Il n'y a pas de timeout au niveau de fms, les 50 secondes du dispatcher doivent être atteintes les 3 fois (on reessaye 3 fois le temps du timeout avant de renvoyer une erreur).

Est-ce que le serveur fms tourne bien ?

D'après la trace j'ai l'impression que le dispatcher a comme adresse pour fms "no response from tcp://:5556" donc tcp://:5556 et qu'il essaye de contacter cette adresse là qui est clairement incohérente.

Tu peux me montrer le fichier de configuration de fms et le cas échéant celui d'initialisation du dispatcher (fichier option qui permet à un dispatcher de démarrer sur une infrastructure donnée) ?

bdepardo commented 11 years ago

On 2013-02-14 10:55:02 +0100, 'Samuel Kortas (samuel.kortas@edf.fr) wrote: j'ai mis 500 pour le timeout du dispatcher et le poblème est le meme. De plus les messages W: no response from tcp://*:5556, retrying ..

apparaissent très vite au bout de quelques secondes (<3)

le fms tourne et cela se passe bien pour aster4

voici le fichier de config dispatcher

disp_uriAddr=tcp://130.98.90.24:5560

disp_uriSubs=tcp://130.98.90.24:5561

disp_initFile=/home/vishnu30/.vishnu/3.0/init_dispatcher.cfg

disp_timeout=500

disp_nbthread=2

voici le fichier de config fms

vishnuId=1 databaseType=postgresql databaseHost=claui2q1 databaseName=vishnu30 databaseUserName=vishnu_user databaseUserPassword=vishnu_user databaseConnectionsNb=5 sendmailScriptPath=/home/vishnu30/local30/vishnu/3.0/sbin/sendmail.py vishnuMachineId=MA_1 uri=tcp://*:5556 uriDispatcherSub=tcp://130.98.90.24:5561 urlSupervisor=http://130.98.90.24:9001

intervalMonitor = 1

bdepardo commented 11 years ago

On 2013-02-14 11:06:55 +0100, 'Kevin Coulomb (kevin.coulomb@sysfera.com) wrote: Tu peux modifier le fichier de configuration du dispatcher en remplacant la clé "disp_timeout" par "timeout" ?

bdepardo commented 11 years ago

On 2013-02-14 11:34:33 +0100, 'Samuel Kortas (samuel.kortas@edf.fr) wrote: si je modifie disp_timeout en timeout :

what(): VISHNU Error 12 : Undefined configuration parameter [disp_timeout ] Abandon

si je mets les deux le probleme persiste et le dispatcher ne semble pas reconnaitre l'option timeout seul (pas d'impression de la variable en début d'execution)

SK

bdepardo commented 11 years ago

On 2013-02-14 11:44:22 +0100, 'Kevin Coulomb (kevin.coulomb@sysfera.com) wrote: Ok c'est que le paramètre de timeout s'appelle "timeout" maintenant on a uniformisé les fichiers de configuration. Je me disais vu que le timeout a pas l'air pris en compte peut etre c'est la version avec l'uniformisation déjà.