Autre chose qui n’a peut-être rien à voir mais j’ai une puce qui me gratte l’oreille: depuis la 5.1.25, j’ai remarqué que le nombre de sessions “privées” affichées sur le monitoring interne et de sessions “API” restituée dans l’écran “Vider le cache” est incrémenté beaucoup plus qu’il n’est décrémenté.
J’ai surveillé de près pour vérifier que ça reste sans incidence sur le runtime (consommation de ressources CPU/mémoire/threads corrélées à peu près au nombre de sessions “uniques”) avant de revenir vers vous.
La gestion des grants APIs a été profondément refondue en 5.2+ (notamment pour être indépendant d’une session Tomcat technique => plus de valve).
En 5.1 ce n’était pas idéal et les compteurs ne doivent pas toujours faire ce qu’il faut. Mais comme la 5.1 est en fin de vie, je propose d’investiguer ça plutôt après la release de la 5.2.
Oui, rien de bloquant en effet.
Je remontais juste l’info au cas où.
On prépare le terrain pour la 5.2 (on a encore quelques dettes à régler / bootstrap, AUTH_PROVIDERS , …).
Oui d’ailleurs il va falloir prévoir de faire qques tests API avec le token issu de votre IdP, c’est le genre de chose qu’on a toujours du mal à tester => il doit forcément y a voir des choses à “polisher” à ce niveau avant la release de la 5.2
La petite liste du clear cache ne présente que les sessions en cours d’activité (triées par last active date) = en général on veut tuer les sessions UI. l’objectif n’est pas de lister les 119 sessions ici.
Perso ça m’aide à savoir si je clique sur le bouton du milieu ou celui de droite…
Sinon oui le count des API n’aura surement plus rien à voir à l’avenir suite à la refonte des sessions Tomcat API. Dans ce écran il faudra voir comment présenter l’activité API en plus des sessions UI et des cron en cours d’exécution.
Actuellement, si c’est OK pour la partie OIDC flow (cf. click sur bouton “Sign in with renault”), ça coince toujours sur la validation d’un token fourni lors d’un call API (erreur “Invalid token”).
Dès que je restaure l’ancienne configuration en supprimant le paramètre AUTH_PROVIDERS et en remettant en ligne les paramètres OAUTH2_*, le même call fonctionne (avec le même token).
J’ai a priori bien vérifié toute la conf…
NB: cette instance est en 5.1 mais on peut l’upgrader en 5.2 pour tester (j’ai toujours mes environnements internes en 5.1 pour comparer).
J’ai passé en revue tous les modules métier installés et ajusté les paramètres.
Actuellement, il n’y a plus aucune erreur sur cette instance lors du clear cache ou lors du start ou lors de l’instanciation des objets du modèle (à ceci près qu’il n’y a pas de données métier - ou très peu, et hors dépendances avec des assets dans l’Intranet Renault comme mes buckets S3 internes).
Oui bien sûr… Mais comme ça j’ai “pris note” du comportement général (et des quelques exceptions résiduelles surtout) en 5.1. ça me fera gagner du temps pour isoler et analyser les différences de comportement en 5.2.
Une révision 5.1.28 est en train d’être poussée avec qques corrections sur les expirations de tokens + un mode “retry” sur les objets services Simplicité.
Ca devrait résoudre tes pbs (du coup tu peux retirer ta surcharge de postLoad qui normalement ne sert plus à rien)
Super, merci bcp.
Tu peux upgrade l’instance bcsi.renault.simplicite.io quand tu veux en 5.2.
Je me suis initialisé un environnement bcsibeta en 5.2 “sortie de la boîte” pour avoir une référence propre (et j’ai supprimé l’ancien bcsidev dont je ne me servais plus).
J’ai mis à jour mes 6 environnements internes & AWS (dev/tests/prod) en 5.1.28 pour être sûr que les appelants/appelés soient bien en phase.
Bonjour David et Bruno,
Si je synthétise les échanges, nous pouvons refaire les tests avec la version 5.1.28 concernant le problème des nouveau token, c’es bien ça?
NB: Entre temps il y a eu une révision 5.1.29 et une nouvelle révision 5.1.30 sera mise à dispo aujourd’hui. Je vous conseille de toujours utiliser la révision la plus à jour dans tous le cas.
(et sur la