Depuis la version 12c, WebLogic Server expose certains de ces services au travers d’une interface RESTFUL. Vous pouvez consulter la documentation officielle pour avoir davantage d’informations sur le sujet.
Ceux connaissant déjà les fondamentaux des API REST ont du être surpris par le titre de l’article mentionnant les sessions HTTP.
En effet, une architecture REST stipule que le serveur est SANS ETAT. C’est à dire que le client doit envoyer systématiquement toutes les informations requises au serveur afin qu’il puisse traiter sa requête. Le serveur ne conservant aucune information sur le client une fois la requête traitée.
Revenons à WebLogic Server. Il expose donc pas mal de services d’administration au travers d’une API REST qui permettent de consulter ou de modifier la configuration du domaine ainsi que de consulter les métriques des composants pendant le run.
L’appel d’une simple URL telle que http://<host>:<port>/management/weblogic/latest/serverRuntime permet par exemple de récupérer les métriques de fonctionnement du serveur.
Or, pour dialoguer avec l’API il faut être authentifié, ce qui semble normal pour éviter que n’importe qui accède à ces informations ou déclenchent inopportunément des actions sur les serveurs.
Le problème est que cette authentification provoque la création d’une session HTTP au niveau du serveur.
Le contexte web « /management » est géré par l’application web interne wls-management-services.war
Le timeout de session est fixé à 3600 secondes (1 heure) sur cette application web.
En conséquence et s’il on n’y prend pas garde, chaque appel vers l’API REST va créer une nouvelle session dans le serveur et donc consommer de la mémoire.
Les tests que j’ai réalisé sur une version 12.2.1.3 montrent que les sessions HTTP sont d’une taille d’environ 1,7 Ko
C’est pas énorme mais cet effet de bord est à prendre en considération si le nombre d’appels REST est important.
Pour éviter la sur-multiplication des sessions il faut réutiliser le cookie de session JSESSIONID qui sera renvoyé par le serveur lors de la 1ère requête.
A noter également, que l’API ne propose pas de déconnexion pour supprimer (invalidate) la session HTTP.
Bonne lecture.