HC3 erreur erratique HTTP request

[yves.guern]

Bonjour,

J'ai besoin d'idées, celles que j'ai vue sur le forum n'ont pas suffit...

 

Je suis passé récemment de HC2 à HC3 et j'ai quelque chose qui tourne bien, de façon stable depuis juillet.

'Stable' ou presque : sur une trentaine de QA, 3 plantent régulièrement (au moins une fois toutes les 48h) avec cette merveilleuse sortie console:

[28.11.2023] [13:35:47] [ERROR] [QUICKAPP167]: QuickApp crashed

[28.11.2023] [13:35:47] [ERROR] [QUICKAPP167]: Unknown error occurred:

Sortie console qui fait bien avancer les choses et oblige à passer en mode Sherlock

• Je suis passé au firmware 5.150.15 il y a une semaine avec beaucoup d'espoir, mais non, aucun changement.
• Le point commun de ces 3 QAs est de lancer des requêtes (GET ou POST) vers mon NAS (synology) régulièrement (ie toute les 5 mn soit 300 appels/jour).
  Ces requêtes lancent des scripts en php.
• Aucune des autres QA n'utilise le NAS. Et le nombre d’éventuels request/jour effectué est plus limité.
• J'ai fini par mettre des pcall partout comme Lazer l'explique ici:
• A savoir: un pcall sur le http:request et 2 sur fSuccess() et fError()
  (ie les callback success() et error() appellent, sous pcall, des fonctions locales fSuccess() ou fError())
• Le NAS log les réponses qu'il a envoyé à la fin de l’exécution du request par le NAS

 

A la fin, en cas de plantage, voici ce que j'observe:

• le http:request se déroule correctement et rend la main comme attendu.
• le log du NAS montre que la réponse préparée est bien celle 'attendue' dans des temps constants (<1s)
• cela semble planter avant l'appel des callback success() ou error() qui commencent par un self:debug("Johnny was here").
• => donc le bug n'est pas directement dans mon jardin mais plus profond. Même s'il doit se trouver quelque part entre le clavier et la chaise...

 

D'autre que moi ont-ils eu ce soucis?

 

Vous remerciant par avance...

 

 

PS: J'oubliais de dire qu’après un rebooot de la box (mais pas lors d'un redémarrage ultérieur de la QA), les requests plantent systématiquement pendant 2mn environ: c'est un début de piste?

Modifié le 28 novembre 2023 par yves.guern

[Lazer]

En fait, ce que tu dis, c'est qu'avec pcall(), tu arrives bien à attraper l'erreur, et ton script LUA continue son exécution ?
Donc si c'est bien ça, alors tout va bien, puisque c'est justement la méthode à employer pour traiter les erreurs pour lesquelles on n'a aucun contrôle.

[yves.guern]

Bonjour Lazer,

Non, ce que je voulais dire c'est que les 2 pcall des callback n'attrapent rien, ni succès ni erreur en fait elles ne semblent pas appelées

 

Le request proprement dit est bien envoyé au Nas (et executé)

Mais la QA semble se planter juste avant l'appel de l'une des callback success ou error du request (et cela environ 1 fois sur 500...)

 

Bonne journée

Modifié le 29 novembre 2023 par yves.guern

[Lazer]

Ah OK... bon bah du coup c'est très embêtant.

Est-ce que par hasard, ça ne serait pas une réponse mal formée par le NAS, qui est envoyée à la box HC3, qui ferait planter le code à l'intérieur de la fonction request() ?

On n'a pas vraiment d'outils pour débugger cette étape, mais c'est une piste...

 

Autre chose à savoir aussi : la libraire net.HTTPClient() n'aime pas du tout les requêtes en parallèle, donc assure toi que le code LUA de ton QuickApp effectue bien les requêtes séquentiellement, et jamais 2 en parallèle, c'est à dire en attente de réponses provenant de 2 requêtes distinctes.

[yves.guern]

Sur le premier point: le log des réponses fait sur le nas ne montre pas de message mal formé, cela ne garanti pas qu'il ne le soit pas à 100%

 

Sur le second:

Qu'appelles tu requêtes parallèles? Est-ce que 2 QA différentes qui postent une requête http en même temps  tombe sous cette dénomination? (est-ce que 2 destinations http différentes change la chose?)

 

Si c'est le cas tu viens de me mettre sur une piste très sérieuse/probable:

   3 QA qui font 500 requêtes/jour chacune, plus les autres qui en font beaucoup moins mais quand même, ce serait bien le diable s'il n'y en avait pas 2 simultanées tous les 2 jours...

 

Existe-t-il une solution 'élégante' autre que faire passer toutes les requêtes http par une QA qui ne ferait que cela?

 

Merci

Modifié le 29 novembre 2023 par yves.guern

[Lazer]

Non je parlais bien au sein du même QA, pas dans des QA différents, car les espaces mémoires sont isolés (process différents au niveau OS Linux)

 

En tout cas chez moi j'ai des dizaines de QA, dont certains qui enchainent les requêtes HTTP, et pas de souci particulier.
J'ai juste eu des soucis, notamment avec mon QA Network Monitor, car lui il faisait pleins de requêtes en parallèle vers différents appareils, et ça c'était pas bon du tout.

 

[yves.guern]

Bon alors il ne me reste que l'hypothèse 1 (réponses mal formées...) car les QA qui plantent n'ont qu'un request...

Cela ne va pas être beaucoup plus facile à identifier

 

est ce que d'instancier net.HTTPClient à chaque appel en utilisant

fonction CallHttp( ...)
  local http = net.HTTPClient({timeout=10000})
  http:request( 
  ../..
end

plutôt que:

self.http = net.HTTPClient({timeout=10000})
fonction CallHttp(self, ...)
  self.http:request( 
  ../..
end

pose un problème? (pour l'instant je suis sur la 1ere version)

Modifié le 29 novembre 2023 par yves.guern

[Lazer]

Non en effet... après tu peux tenter de contacter le support Fibaro, mais sur ce genre de problème très pointu, et surtout aléatoire, je n'ai pas beaucoup d'espoir.

[yves.guern]

Ma correction a croisé ta réponse avec laquelle je suis bien d'accord...

[Lazer]

Ah j'avais pas vu.

Non il ne faut pas la ré-instancier à chaque appel, il vaut mieux l'instancier une bonne fois pour toute durant la vie du QA, un des meilleurs endroits pour ça c'est dans le onInit()

 

Il y avait une vieille discussion sur ce sujet là quelque part sur le forum.

[yves.guern]

Merci, je vais commencer par là...

[henri-allauch]

Il y a 18 heures, Lazer a dit :

Il y avait une vieille discussion sur ce sujet là quelque part sur le forum.

 

Oui on avait fait des essais pour conclure une seule déclaration net.HTTPClient  dans le Init()

Par ici

[yves.guern]

Bonsoir,

Je suis légèrement en train de vendre la peau de l'ours (mon test n'est pas encore assez long) mais cela semble fonctionner (ie avec un self.http).

Le bug était bien entre le clavier et la chaise !

Finalement le plus extraordinaire était que cela fonctionne 500 fois ou plus avant de planter, la même chose en C aurait explosé au premier essai.

Cela fait partie des mystères de LUA et de son Garbage Collector .

 

En tous cas merci à vous deux!

 

Je profite de votre attention pour poser une question qui n'a qu'un rapport indirect

La récupération de l'adresse IP externe de ma LiveBox5 se fait par 4 ou 5 requêtes http. La première utilise un cookie que je n'ai pas su 'manipuler' avec la HC3, je passe donc par un php sur mon NAS pour le faire (script interrogé par l'une des 3 QA qui plantent plantaient)

L'un de vous a-t-il eu a faire à ce genre de requête à cookie et trouvé une solution 100% HC3?

 

 

[Lazer]

Ah oui le C j'aime bien, c'est vrai qu'on est vite fixé sur notre sort dès qu'on fait une boulette, ça pardonne pas !

 

Oui sur HC3 tu peux manipuler les cookies, car la librairie net.HTTPClient() te renvoie tous les headers de la réponse, ce qui permet de récupérer les cookies.
Et de même, on peut ensuite envoyer les cookies en les positionnant dans les headers de la requête.

 

Voir mon mini tuto, il y a un exemple de définition de quelques headers.

 

[yves.guern]

Merci Lazer d'avoir poussé ma curiosité jusqu'à lire jusqu'au bout (et en détai)l le résultat de

--/--
success(response)
  print(response)
end,
--/--

Cela et F12, il y a effectivement tout ce qu'il faut pour manipuler les 'gateaux'.

 

Je n'ai plus besoin du Nas pour interroger ma Livebox et récupérer son IP, je considère que c'est un progrès !!!

 

Je vais quand même me permettre de continuer à faire diverger ce sujet:

Il y a un http:request vers la Livebox qui me répond en mode "Transfer-Encoding: chunked"

Donc je ne récupère rien ou pas grand chose d'autre que le header (et c'est d'autant plus frustrant que les data font moins de 500 bytes)!

Le header de mon request indique que je ne connais que ["Accept-Encoding"]= 'gzip, deflate' , cela n'a pas l'air d'intéresser mon correspondant...

 

Il existe des solutions sous connexion TCP mais apparemment la livebox5 ne propose pas de serveur TCP.
Et avec les mots clefs  http et Chunked je n'ai pas trouvé de piste sur les forum

 

Ce n'est pas indispensable mais serait utile pour surveiller le trafic (en byte/s) de la connexion...

Si vous avez une idée...

[Lazer]

Perso je remonte les statistiques de débit montant/descendant de ma connexion Internet en interrogeant mon routeur Ubiquiti avec le protocole SNMP, qui est un standard pour ce genre d'usage.... mais pas sûr que la Livebox connaisse ce protocole.

[yves.guern]

Bonjour,

Comme dit plus haut, j'ai soupçonné le HTTPClient de la HC3 de ne pas être compatible des réponses de type "Transfer-Encoding": " chunked" (ie réponses qui arrivent par morceaux).

 

En fait, une fois enlevé le 's' qui était en trop dans un cookie, cela fonctionne très bien et de façon transparente (on récupère le paquet entier d'un seul coup)!

Comme d'habitude le problème se situait entre clavier et chaise.

 

Maintenant j'interroge ma LiveBox 5 sans intermédiaire depuis la HC3.

En plus des "données de base" (IP,état du téléphone, de la télé,...) je récupère également des infos sur le débit réel montant/descendant.

 

Merci pour vos coups de main

[Lazer]

Super