Re: [openplacos-dev] amélioration stabilité

[flagos <flagospub@xxxxxxxxx>]

@kirsh

Faudrait essayer la manipe de creer un arduino virtuel qui repond aux
string envoyés sur un fichier quelconque (qui emule /dev/arduino
quoi). On pourrait peut etre reproduire des problemes en full soft.

@rom

Pour la non-réponse on est pas encore fixé, mais pour l'instant on
partirait bien sur monit. Je sais pas si tu connais ce soft, ca permet
de monitorer des ressources (en general apache, mysql, etc) en
greppant sur des fichiers de log, ca informe le user et ca prend des
mesures correctives (restart du service, reboot machine..).

Il y a un exemple d'utilisation dans la doc ubuntu:
 http://doc.ubuntu-fr.org/monit

Pour opos, on aurait plus qu'a lui indiquer le fichier de log et a lui
filer un regexp pour trigger les erreurs.

Ca nous paraissait pas trop mal, je l'utilise en prod pour un serweb
web et ssh, j'en suis content. Ca conviendrait a tes besoins ?

Le 13 août 2012 17:58, rom .. <lsdark73@xxxxxxxxx> a écrit :
> Comment réagit le serveur en cas de non réponse ?
> Il y a au moins 2 cas à gérer :
> - Un composant critique ne répond pas (chauffage par ex.)
> - Un composant non critique ne répond pas (afficheur lcd)
> Dans les deux cas, remontée d'alarme ?
>
> Le 13 août 2012 17:49, "miaouf kirsh" <miaoufkirsh@xxxxxxxxx> a écrit :
>
>> yep,
>> ben pour l'arduino, c'est pas evident.
>> il me semble avoir callé un timeout, c'est meme sur :
>> https://github.com/openplacos/openplacos/commit/89f2a416d2cc54f855f53478b3dfbaed48dada46
>>
>> j'ai callé 2 truc, le premier, c'est lors de l'initialisation de la
>> connexion, (au lancement du composant), on attend que l'arduino reponde a
>> une commande quelconque. ca bloque le lancement du server tant que l'arduino
>> est pas ok, de maniere a pas accepter de requette si l'arduino est pas pres.
>> ca evite de tomber dans le fameux trou noir au lancement du server.
>>
>> le deuxiemme, c'est au write, si l'arduino repond pas en 1s, on leve une
>> erreur. le truc c'est que je c pas trop comment ca se passe la propagation
>> de l'erreur. le truc c'est que c'est pas super evident a tester.
>>
>> enfin, coté firmware, j'ai activé le watchdog interne de l'arduino pour
>> qu'il reset si jamais il plante. ca j'ai pu testé, a priori le composant le
>> voit meme pas et tout se passe bien, a moins de faire une requette pendant
>> le boot de l'arduino, mais la le timeout du composant devrais prendre en
>> compte l'erreur.
>>
>> la derniere fois, avec JF, on a eu des plantages, mais je serais incapable
>> de dire ce qui se passais, ni comment les reproduire.
>>
>> Le 13 août 2012 17:19, flagos <flagospub@xxxxxxxxx> a écrit :
>>>
>>> On pourrai se faire un composant qui repond pas, juste pour tester.
>>>
>>> Toutafé. Quel serait le usecase: Tu fais un appel sur le composant
>>> blackhole, tu es coincé.
>>>
>>> 1. on est censé avoir un timeout
>>> 2. on est censé pouvoir faire des read sur d'autres objets
>>>
>>> Il faudrait faire des tests sur ces 2 cas ?
>>>
>>> je pense qu'il faut, au niveau de l'arduino, se faire le truc de
>>> maniere asynchrone. pour le moment, on envoi la requette sur l'usb, et
>>> on attend un retour (appel bloquant "gets"). on pourrais se le faire
>>> de maniere asynchrone, pour eviter de bloquer sur un gets qui nous
>>> complique la gestion des erreurs.
>>>
>>> Il faut je pense parler de la testabilité du truc (= le reproduce en
>>> non-reg). Pour l'arduino c'est hardware dépendant. On peut peut-etre
>>> émuler la carte avec un deuxieme process qui ferait les print qui vont
>>> bien histoire de caler ca en non-reg.
>>>
>>> Cela dit, tu avais pas deja calé un timeout pour ca ? Ca ne suffit pas ?
>>>
>>> Le 13 août 2012 15:27, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
>>> > alors je dirais qu'on a principalement deux problème.
>>> > un générique, qui est que si un composant, pour une raison ou pour une
>>> > autre, ne repond pas a une requette, ca va bloquer le server.
>>> >
>>> > On pourrai se faire un composant qui repond pas, juste pour tester.
>>> >
>>> > le deuxiemme, c'est avec l'arduino, en cas de plantage / perte de
>>> > connexion
>>> > de l'arduino.
>>> > souvant, quand tu manip et que tu branche les truc un peut a l'arrache,
>>> > il
>>> > est possible qu'on ai un reset de la bete, et ca fout un peut la merde.
>>> > donc
>>> > ya encore un peu de boulot a faire pour le rendre plus robuste.
>>> >
>>> > je pense qu'il faut, au niveau de l'arduino, se faire le truc de
>>> > maniere
>>> > asynchrone. pour le moment, on envoi la requette sur l'usb, et on
>>> > attend un
>>> > retour (appel bloquant "gets"). on pourrais se le faire de maniere
>>> > asynchrone, pour eviter de bloquer sur un gets qui nous complique la
>>> > gestion
>>> > des erreurs.
>>> >
>>> > Le 13 août 2012 14:10, flagos <flagospub@xxxxxxxxx> a écrit :
>>> >
>>> >> Yop,
>>> >>
>>> >> Certains d'ente vous ont fait des manipes avec openplacos, version
>>> >> unstable et testing. Kirsh m'a notamment dit qu'il avait eu des soucis
>>> >> de stabilité du serveur lorsqu'on fait un peu joujou avec.
>>> >>
>>> >> Etant donné qu'on commence a avoir une testsuite un peu couvrante, je
>>> >> me dis que ce serait bien qu'on la complete en prenant en compte ce
>>> >> genre de retours, et en essayant de coller un peu mieux au système
>>> >> physique lors de noter non-reg.
>>> >>
>>> >> Qu'est ce que vous avez eu comme soucis ? Comment les reproduire ?
>>> >>
>>> >> --
>>> >> Tapé depuis mon clavier
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Tapé depuis mon clavier
>>>
>>>
>>
>



-- 
Tapé depuis mon clavier