Mon besoin est le suivant :
Je cherche à interroger, depuis un front externe à Simplicité, différentes ressources via du multithreading. Chaque ressource que je dois interroger est donc requêtée via un thread différent, en passant par les APIs de mon environnement Simplicité.
Steps to reproduce
Mon soucis est le suivant :
This request concerns an up-to-date Simplicité instance
and these are the steps to reproduce it:
Je réalise un clear cache qui vide toute les sessions et caches serveur (besoin ponctuel qui est à l’origine du soucis que je recontre)
Une fois le clear cache achevé, j’exécute la recherche du côté de mon Front. Cela entraine le lancement de plusieurs requêtes (multithread) aux APIs de mon environnement Simplicité.
Cela déclenche une erreur sur mon environnement Simplicité. Erreur que voici :
2023-08-04 12:09:32,474|SIMPLICITE|ERROR|RewriteFilter URI mapping error: Cannot invoke "com.simplicite.webapp.WebServicesFactory.returnExternalObject(com.simplicite.util.ExternalObject)" because the return value of "com.simplicite.util.Grant.getWebServicesFactory(boolean)" is null
2023-08-04 12:09:32,472|SIMPLICITE|ERROR||http://4489d0292525:8080||ERROR|system|com.simplicite.commons.RenaultAPI.RESTTranslatedObjectExternalObjectCommons|get||Event: Exception thrown by IndexCore.searchIndex(terms:test ,into:businessDataObjectCharacteristics)
java.lang.NullPointerException: Cannot read field "m_maxRows" because "this.m_data" is null
at com.simplicite.util.GrantCore.getMaxRows(GrantCore.java:1019)
at com.simplicite.commons.RenaultAPI.RESTTranslatedObjectExternalObjectCommons.get(RESTTranslatedObjectExternalObjectCommons.java:1715)
...)
Question
Il semblerait, par cette erreur, que chacune des requêtes envoyés à l’API de mon environnement Simplicité tente l’ouverture de la session technique propre à mon Front. Cette erreur n’intervient qu’après un clear cache de sessions et cache serveur.
Quel serait la solution pour qui me permettrait de m’assurer que si une première requête déclenche l’ouverture de ma session technique, les autres requêtes puissent être “mises en attente” le temps que la session soit ouverte, plutôt que de tenter à nouveau de forcer son ouverture.
Potentielle solution de contournement ?
Y aurait-il un hook qui serait exécuter tout de suite après achèvement d’un clear cache afin de forcer la réouverture d’une session technique?
OK, est-ce que vous utilisez des appels authentifiés (avec token) ou anonymes sans token ?
En 5.2+ il n’y a plus de “session” au sens Tomcat pour les appels d’API c’est des grants associés aux tokens, il y a peut être un pb de synchronisation lors de la montée en mémoire d’un grant API lié au même token utilisé en //
Ensuite pour un objet donné (pour une instance d’objet donné pour être précis) il y a bien une synchronisation des appels API.
Je ne pense pas que ça soit lié mais utilisez vous l’object pooling (para systeme USE_WEBSERVICES_OBJECTPOOL) ?
Ce sont bien des appels authentifiés (avec token).
On suppose qu’il y ait un problème de synchronisation lors de la montée en mémoire d’un grant API lié au même token utilisé en en parallèle.
Concernant l’object pooling “USE_WEBSERVICES_OBJECTPOOL”, il est bien présent dans nos paramètres système mais nous ne faisons pas appel dans le cadre de notre feature
Par principe la montée en mémoire des grants API ne peut pas être totalement synchonisée pour ne pas pénaliser les performances en cas d’appels massifs avec des tokens différents (la montée de grants API différents pouvant être faite en //). Le niveau de synchronisation en place pose peut être pb en cas d’appels massifs avec le même token.
PS: concernant USE_WEBSERVICES_OBJECTPOOL si la valeur est no cela signifie que vous n’utilisez pas cette feature. Celle-ci est intéressante - et donc recommandée - dans le cas où un même token est utilisé pour des appels en // sur un même objet, sinon ça n’a pas d’intéret (NB: ça peut être activé par user)
Pas à ma connaissance sur d’éventuels autres systèmes souscripteurs de nos APIs, mais pour ce qui est du front dont je parle dans le topic, les appels APIs vers notre environnement Simplicité ne sont initiés qu’après exécution du clear cache
Autre question, y-a-t-il une bonne raison de ne pas être encore passé en 5.3 ?
En effet la 5.2 est désormais en maintenance court terme (3 mois) jusqu’en septembre.
La 5.3 sera, elle, en maintenance long terme (3 ans à dater de la release de la future 6.0 prévue à horizon de fin d’année), il est donc souhaitable de passer en 5.3 dès que possible.
Nous sommes en train de réaliser une migration de nos instance vers le cloud. Nous effectuerons la montée de version dès que la migration sera faite. SauraIt-on si le problème que nous rencontrons en 5.2.44 se résout en 5.3, auquel cas nous pouvons attendre la montée de version pour le soucis détaillé dans ce topic
En fait, en première analyse, pour faire les choses mieux en termes de locking/synchronisation dans votre cas il va nous falloir envisager une évolution un peu subtile du cache des grants API. Nous le feront en 6.0 et nous le backporteront en 5.3 si et quand ça aura été extensivement testé/validé.
Par contre ça ne sera pas backporté sur une version 5.2 qui est désormais en phase de maintenance court terme (i.e. en fin de vie) et n’est donc plus éligible à recevoir ce type d’évolution. D’où ma suggestion d’envisager un upgrade en 5.3.
En attendant la solution plus “bête et méchante” qui peut être envisageable rapidement en 5.3 (et qui est, à priori, backportable en 5.2) c’est de synchroniser plus globalement la (re)montée en cache des grants API, ça garantira l’unicité de la (re)montée d’un grant API unique dans le cas d’appels massifs en // avec le même token (votre cas) mais ce ne sera pas forcément idéal pour les performances dans le cas potentiel de la (re)montée massive en // de grants API associés à des tokens distincts.
Les révisions en question seront releasées d’ici demain donc une solution de contournement n’est pas nécessaire, surtout qu’il n’existe pas de hook post clear cache
