Description du problème
Même s'il est en général déconseillé de lancer des traitements trop longs directement en client léger il peut arriver que certaines actions longues (plusieurs minutes) soient quand même réalisées en client léger. Dans certains cas le traitement peut échouer à cause des timeouts.
Piste de résolution n°1 : améliorer les performance du traitement
C'est la première piste à creuser lorsqu'un traitement est long. Il arrive fréquemment que le traitement réalisé ne soit pas optimisé.
Piste de résolution n°2 : utiliser l'instruction OJS "withmonitoring()"
Lorsque le traitement qui pose problème est un script OJS il est possible de forcer des échanges réguliers entre l'applet et le serveur grâce à l'instruction "withmonitoring()" qui contiendra le traitement long que l'on souhaite monitorer.
withmonitoring(true)
{
//script du traitement
}
Cela permettra en plus d'afficher un indicateur sur l'avancement du traitement. Cette astuce recommandée par l'éditeur peut être très utile et n'implique aucune modification des valeurs des timeouts Apache ou Planisware.
Piste de résolution n°3 : modifier la valeur des timouts Apache / Planisware
Cette dernière piste ne doit être utilisée qu'en dernier recours. Elle consiste à modifier la valeur des timouts Apache et/ou Planisware pour éviter que la requête envoyée au serveur n'échoue à cause d'un timeout.
Localisation des paramètres de timeout :
Il existe plusieurs timeouts qui, s'ils sont mal paramétrés, peuvent être sources des problèmes (erreurs, plantages,…) lors de traitements longs.
- Timeouts Plansiware : Les timeout Planisware sont des paramètres. On peut donc les consulter en client lourd via la liste des "Autres paramètres" (Données > Paramètres > Autres paramètres). Ils sont regroupés sous "Intranet Server" (filtre OPX2 => ID = "*TIME*OUT*" )
Voici leur description :
| ID | Description |
| *IDLE-APPLET-TIMEOUT* | Ce délai en minute est utilisé pour supprimer les applets qui n'ont pas été utilisé au dela d'une certaine période. Ce paramètre est utile pour libérer les ressources du serveur des sessions qui ne sont plus utilisées et qui n'ont pas fait l'objet d'une déconnexion de l'utilisateur |
| *APPLET-TIMEOUT* | Ce délai est le délai maximum utilisé lorsque l'applet Java envoie une requête au serveur OPX2, si ce délai est expiré l'applet abandonne la requête et envoie un message à l'utilisateur |
| *SERVER-TIMEOUT* | Ce délai est le délai maximum que le serveur doit attendre lorsqu'il envoie une requête à l'applet JAVA. Si le délai est expiré le serveur abandonne la requête en cours mais n'envoie pas de message à l'utilisateur. (si le délai est expiré cela signifie que la communication avec l'applet n'est plus possible) |
| *PROCESS-LOCK-TIME-OUT* | |
| *RECALL-TIME-OUT* | |
| *USER-TRANSACTION-TIME-OUT* |
- Timeout Apache : il existe un timeout global apache qui concerne toutes les requêtes transitant par le serveur Apache. En cas de dépassement de ce timeout on peut constater une erreur dans les fichiers de log Apache.
Exemple d'erreur Apache présente dans le fichier de log error.XXXXX :
[Tue Mar 12 10:50:59 2013] [error][client XXX.XXX.XXX.XXX] (70007)The timeout specified has expired: Timeout(400000000) reading HTTP retcode from server 127.0.0.1:8400\n
Ici le traitement à planté au bout de 400 secondes qui correspondent à la valeur du paramètre Apache "Timeout" que l'on retrouve dans les fichiers de configuration Apache (par exemple httpd.conf).
Timeout 400
Attention : si ce timeout se déclanche avant les autres timeouts Planisware l'applet Planisware va planter car il va perdre sa connexion au serveur. On n'aura aucune erreur côté serveur. Après un message d'erreur dans la console java l'applet va être relancé pour établir une nouvelle session avec le serveur.
[2013/03/04 16:34:05.473 (TN=1153)]** HTTP Request url : http://my_server:8000/BASE_DEV/OPX2/localhost:8401/ottp
[2013/03/04 16:38:05.586 (TN=1153)]ERR : DEB(Thread[Planisware GetInputStreamThread,4,http://my_server:8000/BASE_DEV/java/-threadGroup]):GetInputStreamThreadExceptionin GetInputStreamThread.run in while
[2013/03/04 16:38:05.586 (TN=1153)]Server returned HTTP response code:500 for URL:
http://my_server:8000/BASE_DEV/OPX2/localhost:8401/ottp
java.io.IOException: Serverreturned HTTP response code: 500 for URL:
http://my_server:8000/BASE_DEV/OPX2/localhost:8401/ottp
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(UnknownSource)
at opx2.Opx2HTTPConnection.getDecodedInputStream(DialogServerRunnable.java:1241)
at opx2.GetInputStreamThread.run(DialogServerRunnable.java:1477)
[2013/03/04 16:38:05.587 (TN=1153)]java.runtime.name : Java(TM) SE RuntimeEnvironment
[2013/03/04 16:38:05.587 (TN=1153)]java.vm.name : Java HotSpot(TM) ClientVM
[2013/03/04 16:38:05.587 (TN=1153)]java.quick.starter : <no value>
Modification temporaire des timeout Planisware :
Planisware permet en OJS de modifier à chaud la valeur de ses paramètres, notemment celle des timeout. Ainsi il est possible d'augmenter la valeur d'un timeout avant d'exécuter le traitement puis de rétablir le timeout à sa valeur initiale à la fin du traitement.
Exemple de modification temporaire du timeout de l'applet Java (code OJS) :
context.APPLET_TIMEOUT = 300;
Ici le timeout de l'applet Java va passer à 5 min (300 secondes). Cette modification n'étant pas enregistrée dans un ensemble de paramètre cette modification ne sera pas conservée au prochain redémarrage. En général lorsqu'on modifie un timeout pour un traitement on le rétablit à sa valeur initiale à la fin du traitement pour éviter tout effet de bord indésirable.
