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

[flagos <flagospub@xxxxxxxxx>]

Je complete d'ailleurs pour monit. Il est également capable
d'effectuer un test fonctionnel genre un accès web, ouvrir une
connection ssh.

Le 13 août 2012 18:08, flagos <flagospub@xxxxxxxxx> a écrit :
> @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



-- 
Tapé depuis mon clavier