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

[ Thread Index | Date Index | More lists.tuxfamily.org/openplacos-dev Archives ]


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





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/