On a pu améliorer le code du Grant.changeLang afin que celui-ci ne reset plus la date d’expiration du token (c’était bien là que cette date se perdait). Ce sera poussé dans la prochaine révision (5.1.34).
Cela dit, comme le dit @Francois, il vaut infiniment mieux simplement utiliser getGrant().setLang("xxx") qui évite de faire un rechargement complet du grant qui est une opération beaucoup plus couteuse qui doit donc gravement pénaliser vos perfs d’autant que vous la faites 2 fois car vous restaurez la langue initaile à la fin.
Il serait, de toute façon, plus judicieux de ne pas faire ce forçage de langue du grant dans chaque service, mais une seule fois par session API = au niveau du PlatformHooks.
Autre point important: Dans un contexte API il est préférable d’utiliser les objet poolés.
Donc pas de getGrant().getTmpObject("MonObjet") qui instancie un objet en dehors du pool, mais plutôt quelque chose du genre:
WebServicesFactory wsf = getWebServicesFactory();
ObjectDB obj = null;
try {
obj = wsf.borrowObject("MyObject"); // Borrows an object from the pool
addObject("monobj", obj.getName(), obj.getDisplay());
ObjectField f = obj.getField("myField1");
addField("monobj", "monfield1", f.getFullInput(), f.getDisplay(), f.getHelp());
f = obj.getField("myField1");
addField(SUPPLIERS, "monfield2", f.getFullInput(), f.getDisplay(), f.getHelp());
// Etc.
} finally {
wsf.returnObject(obj); // Returns the object to the pool
}
ATTENTION: il faut impérativement respecter ce pattern de codage (= le borrowObject sous un try et le returnObject dans le finally correspondant) sinon vous risquez potentiellement de ne pas libérer l’objet poolé ce qui posera forcément de gros problèmes, à fortiori sous forte charge.
Salut David,
Effectivement, j’ai testé de mon côté et je suis arrivé à la même conclusion. Le soucis vient bien du changeLang().
Je me souviens d’ailleurs que vous aviez déjà fait la remarque lors de l’audit au mois de décembre.
Ce que nous allons faire, c’est installer la 5.1.34 de manière iso-code.
Je vais ensuite prendre les éléments que vous avez fourni ici et écrire une US de refactoring.
Merci en tous cas de votre réactivité et de la qualité de votre support.
Ok tant mieux ! Ca aura été bien compliqué de débusquer la cause du pb cette fois-ci…
Le fait qu’il n’ait pas été visible dans une révision plus ancienne était, je pense, lié au fait qu’un appel fait avec un token expiré ne détruisait pas immédiatement la session API correspondante (= le grant et son pool d’objets), celle si étant flushée plus tard par tâche cron.
On devrait normalement pouvoir pousser la 5.1.34 ce soir.
Une fois upgradé, ne trainez pas trop à refactorer, au moins, vos 2 changeLang en 1 setLang car ça doit avoir un impact significatif sur les perfs.
Le point sur l’utilisation d’objets poolés vs des objets temporaires obtenus par getTmpObject dans le init de vos services est moins urgent, mais ça nuit à la mémoire car les objets temporaires restent en mémoire sans être plus jamais utilisés (puisqu’ils ne sont pas dans le pool) et ce tant que le grant API qui les a créés n’est pas détruit. S’il y a de nombreux services utilisant de nombreux objets métier et de nombreuses sessions API ça peut finir par être très impactant pour la mémoire.
Oui, effectivement ça a été compliqué. On a commencé à parler du changeLang(). Ce sera corrigé rapidement. J’ai pris note des autres points, je vais créer des US techniques.