Notions de timeout en contexte eGx

Introduction

Dans l’architecture eGX, on peut trouver des notions de timeout à différents niveaux et provoquant chacun des comportements différents.

Gestion des sessions Java

Pour gérer les transactions dans un contexte HTTP, donc par définition déconnecté, le serveur d’application conserve en mémoire tout le contexte de l’utilisateur, et identifie ce dernier par un cookie maintenu en mémoire par le navigateur.

Ce cookie, nommé « JSESSION_ID », accompagne toutes les URL générées ultérieurement par le navigateur

Timeout de session

Le problème est que le serveur d’application n’est pas forcément informé quand un utilisateur ferme sa fenêtre de navigateur.

Pour éviter que ne prolifèrent en mémoire des sessions inutilisées, on utilise un mécanisme de timeout, défini dans le fichier « web.xml » par le nœud « /web-app/session-config/session-timeout ».

Ce paramètre est exprimé en minutes. Il est généralement fixé à 30 (minutes).

Au-delà de ce délai après la dernière action de l’utilisateur, sa session est fermée et les objets détruits ou remis en pool, selon la configuration.

Remarques :

> La licence est libérée soit lorsque l’utilisateur se déconnecte, soit lors du déclenchement de ce timeout.

> Une valeur trop faible risque de faire perdre son travail à l’utilisateur à la moindre interruption

> Par contre, une valeur trop élevée amène une sur consommation de licences.

[[ web.xml ]]

<web-app>

<session-config>

<session-timeout>30</session-timeout>

</session-config>

Lien Apache / OC4J

Les requêtes reçues par le serveur http (Apache) sont retransmises à OC4J par l’intermédiaire du module « mod_oc4j ».

Timeout Apache

On peut également trouver dans les fichiers de log du serveur http (Apache), des messages de timeout.

Contrairement au timeout d’eGX correspondant à une inactivité, celui-ci correspond à un temps de traitement.

Lorsqu’une requête reçue par le serveur Apache et transmise à OC4J n’est pas traitée pendant le temps fixé par ce timeout :

> Apache retourne à l’utilisateur un message d’erreur.

> Un message de timeout est enregistré dans le log Apache.

L’obtention de ce message indique une surcharge système.

Affinité de Load Balancing

Les systèmes de load balancing permettent de répartis les requêtes des utilisateurs entre plusieurs serveurs.

Par contre, afin de gérer la continuité d’une transaction réalisée par plusieurs URL successives, il est nécessaire que toutes ces URL soient traitées par le même serveur.

Pour cela, les systèmes de Load Balancing gèrent une notion d’affinité entre une session et un serveur.

Timeout de load balancing

Cette affinité entre une session et un serveur est également soumise à un timeout.

2 URL successives issues d’une même session pourront être traitées par 2 serveurs différents si le délai entre ces 2 URL est supérieur au timeout.

Ce dernier doit donc être supérieur au timeout de session pour être certain qu’un utilisateur ne soit pas dirigé vers un autre serveur alors que sa transaction est encore en cours.

Gestion des utilisateurs (cookie UUID)

Cookie UUID

eGX permet de suivre les sessions d’utilisateurs, même s’ils ne sont pas identifiés comme dans le cas de « GUEST ».

Cette gestion se fait à l’aide d’un cookie nommé par défaut « UUID » et stocké sur disque côté client.

Cette gestion est activée par défaut.

Elle peut être désactivée en positionnant la propriété : uuidManage="true".

[[ configuration.xml ]]

<public_businessview>

</publicBusinessview>

</properties>

Si la gestion du cookie UUID est activée, il est possible de l’utiliser pour connecter automatiquement l’utilisateur en lui évitant de remplir systématiquement la page de login.

Grâce à l'UUID stocké dans le cookie du navigateur, on reconnaît l'utilisateur précédemment logué et on le ré identifie automatiquement..

Cette gestion des connexions automatiques s’active à l’aide de l’attribut « defaultUserRecognize » :

> "true" : le support de présentation est reconnecté pour l'utilisateur précédemment logué.

> "false" : l’utilisateur est quand même reconnu, mais on l’oblige à passer par la page de login pour contrôle de son identité.

Durée de vie

La durée de vie de ce cookie est déterminée par l’attribut « maxAge », exprimé en secondes.

La valeur par défaut est de 10000 secondes, soir environ 2h45’.

[[ configuration.xml ]]

<link_to_presentation>

<http>

</http>

</link_to_presentation>

Communication avec S2I (UERP)

Dans le cadre de la gestion des éditions rapides, on définit dans configuration.xml le mode d’accès au service S2I du serveur de traitements.

Timeout d’accès

Un timeout peut être défini afin de définir un temps maximal d’attente d’une réponse de la part du serveur xmlRpc.

On évite ainsi de rester bloqué si le service distant n’est pas accessible.

> timeOut

Temps d'attente en secondes de la réponse du serveur xmlRpc. Représente la durée maximale de la boucle de scrutation de la réponse du serveur xmlRpc.

Paramètre ptionnel.

Valeur par défaut de 5 s.

> delay :

Temps d'attente en ms entre deux scrutations de lecture de la réponse du serveur xmlRpc. Permet de limiter la consommation cpu (voir attribut timeOut).

Paramètre optionnel.

Valeur par défaut de 10 ms.

[[ configuration.xml ]]

<link_to_ACE>

</xmlrpc>

</link_to_ACE>