Erreur récurrente à l'appel d'une API Simplicité

Defect
1

Request description

Bonjour,

Nous avons une erreur récurrente à l’appel d’une API. Après redémarrage des serveurs, c’est de nouveau fonctionnel puis retombe quelques jours plus tard.
J’avais ouvert ce ticket à ce propos Erreur à l'appel d'une API Simplicité - #11 by david

L’erreur survient avant l’entrée dans mon API donc le problème ne vient pas du code.
Pouvez vous m’aider à comprendre ce qui peut se passer avant ? Car le problème devient critique chez nous.

Merci

Steps to reproduce

This request concerns an up-to-date Simplicité instance
and those are the steps to reproduce it:

curl -s -k -u [LOGIN]:[MDP] “[BASE URL]/api/login?_output=json”

→ là j’ai un token en retour

curl -X GET “[BASE URL]/api/ext/RciApiList” -H “Authorization: Bearer [TOKEN]”

→ erreur
Cannot read field “m_objects” because “this.m_data” is null

Et si j’essaie une API classique
curl -X GET “[BASE URL]/api/rest/RciApplication” -H “Authorization: Bearer [TOKEN]”

→ retour correct sans erreur

Technical information

Instance /health 
Status=OK
Version=4.0.P25
BuiltOn=2022-03-18 11:41 (revision d81c6d369cb003b957136e8ed8d42cb7e2bbe62e)```
Simplicité logs 
2022-04-19 16:48:35,128|SIMPLICITE|http://simplicite-XXXXXXXXXXXXXXXXXXx:8080||DEBUG|system|com.simplicite.webapp.tools.ServletTool|setHTTPHeaders||Event: [REQUEST] method GET on /api/ext/RciApiList from 10.252.251.71 with session B92D89CEEE04E5D8D827CEB6D677567F, [RESPONSE]  MIME type: text/plain max age: -1 seconds 
 
2022-04-19 16:48:58,257|GLOBAL|INFO|2022-04-19 16:48:57,990|SIMPLICITE|http://simplicite-XXXXXXXXXXXXXXX:8080||DEBUG|system|com.simplicite.webapp.tools.ServletTool|setHTTPHeaders||Event: [REQUEST] method GET on /ui/logs from 10.252.251.71 with session 61E96AEDF12AD672003CFB757BDE3DDE, [RESPONSE]  MIME type: text/html; charset=UTF-8 max age: 0 seconds 
 
2022-04-19 16:48:58,397|GLOBAL|INFO|2022-04-19 16:48:58,394|SIMPLICITE|http://simplicite-XXXXXXXXXXXXXX||DEBUG|system|com.simplicite.webapp.tools.ServletTool|setHTTPHeaders||Event: [REQUEST] method GET on /scripts/core.js from 10.252.251.71 with session 61E96AEDF12AD672003CFB757BDE3DDE, [RESPONSE]  MIME type: text/javascript; charset=UTF-8 max age: 1296000 seconds
Browser logs 
---paste content of the **relevant** browser-side logs---
Other relevant information

----E.g. type of deployment, browser vendor and version, etc.----

3

Indépendamment du pb décrit que nous allons essayer de reproduire (sans doute un pb de rechargement du cache des objets externes ou dans le genre), il serait sans doute souhaitable d’envisager une migration de votre application sur la version 5.x (actuellement 5.2.3) car il y a eu, entre autres, de très grosses améliorations sur la couche API vs la version 4.0 notamment sur les objets externes de type API.

Attention une migration de version majeure nécessite parfois un peu de refactoring de choses deprecated (ou qui n’auraient pas dû être utilisées). Il faut lire avec attention les release notes (notamment le § "compatibility breaking changes (5.0, 5.1 et 5.2) , et, bien entendu, tester d’abord cette migration sur une instance temporaire dédiée avant d’envisager de le faire sur vos vraies instances de dev/test/prod car après un upgrade un downgrade n’est pas possible. Mais le ratio bénéfices/effort de migration est clairement en faveur de la 5.x

4

Oui pour la 5.0 le sujet est en cours chez nous.

Pour les API, après un reboot hier, le service est de nouveau tombé ce matin, une erreur 500 puis 503.
Il faut quasiment un reboot quotidien …

5

En 4.0 et en 5 avant la 5.2 il y avait une session Tomcat “technique” pour les APIs (cette session technique n’est pas sensée expirer). La valve qui gère cette session a été beaucoup refactorée pour la version 5.0 et la 5.1 et ça a peut être un effet néfaste dans le cadre de la 4.0.

Pour essayer de reproduire il faudrait plus d’infos :

  1. séquence exacte de vos appels API
  2. fréquence de ces appels
  3. origine des appel

Etc.
Bref tout ce qui peut nous permettre de tomber dans le même cas.

PS: Sinon pour analyse ce qui se cache derrière le “symptôme visible” (l’erreur 500/503) il nous faudrait les logs complètes correspondant à ces appels en erreur (il y a peut être une stacktrace qui indique où le pb se situe).

6

J’ai reproduit l’erreur “Cannot read field “m_objects” because “this.m_data” is null” sur une 4.0 à jour en appelant une API custom.

Ca ne se produit qu’après avoir fait un appel à /api/logout et obtenu un nouveau token sur api/login puis refait un appel à l’API custom.

Est-ce que ça correspond à ce que vous faites ?

7

Bonjour David et merci pour ton aide,

C’est exactement l’erreur que nous avons chez nous, mais nous ne faisons pas de logout, seulement un api/login puis appel à l’API custom.
Il y a un job toutes les heures qui fait cet appel de façon simultanée sur nos 3 environnements (dev valid et prod).

8

Pour que je comprenne bien, vous créez un token pour chaque appel ? Sans faire de logout explicite ?

Quel est le paramétrage des user tokens (les paramètres en *USERTOKEN*) ?

Indépendamment du pb constaté qui relève sans doute d’un bug qu’on va essayer de cerner/corriger, ce n’est pas la bonne manière de faire => un token API est sensé être réutilisé tant qu’il est valide (ou alors explicitement supprimé par un logout quand il n’est plus utilisé), sinon on multiplie les tokens et les grants associés ce qui finira forcément par saturer la mémoire (NB: tout cela a été sévèrement refactoré / optimisé en 5.2 pour qu’il y ait notamment un garde fou sur ce point).

Pour de l’intégration machine-machine l’idéal (je ne sais plus si c’était déjà possible en 4.0) c’est d’avoir des tokens de durée appropriée vs l’usage effectif (ex: en utilisant des users ad hoc avec une durée d’expiration spécifique).

9

Oui tu as raison il n’y a pas de logout et un nouveau TOKEN à chaque heure.
En effet c’est peut-être la multiplication des TOKEN qui fait tomber les APIs, on va donc ajouter le logout explicite et voir si ça se reproduit !

10

Pas tout de suite car je reproduis le pb justement en cas d’appel explicite au logout (cf. plus haut)

C’est juste que quand ce sera corrigé il faudra ajouter cet appel au logout ou gérer des tokens plus long réutilisés pour ne pas multiplier les sessions inutilement

1 Like
11

Bonjour David,
Le correctif a-t-il été livré ?

Merci !
Emmanuelle

12

Non pas encore, désolé. J’indiquerai ici quand ce sera livré.

1 Like
13

Bonjour,

A mon sens le côté client doit gérer un appel “refresh token” quand il est expiré ou reçoit une erreur d’authent.

Je vois pas bien ce qu’on a corriger car repousser le délai repoussera juste le problème.

14

Non c’est bien un bug. Suite à un logout API correct puis à un login API correct il y a une erreur bizarre lors des appels d’objet externes API.

Ca n’empêche pas de mettre en place un meilleur usage des tokens comme expliqué plus haut mais il y a un truc à corriger de notre coté sur ce cas là de toute façon.

PS: Et comme expliqué aussi plus haut, passer en 5.2, outre les autres bénéfices vs la 4.0, permettrai de bénéficier d’une refonte complète de l’implémentation du endpoint API.

15

Le pb est réglé. Ce sera poussé dans la journée.

NB: C’était un pb spécifique à la 4.0 qui ne concernait que les objets externes API, pour info ça avait été refactoré dès la 5.0

1 Like