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()”

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.

1. 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 :

<td >
  <em><strong>Description</strong></em>
</td>

<td >
  Ce d&eacute;lai en minute est utilis&eacute; pour supprimer les applets qui n'ont pas &eacute;t&eacute; utilis&eacute; au dela d'une certaine p&eacute;riode. Ce param&egrave;tre est utile pour&nbsp; lib&eacute;rer les ressources du serveur des sessions qui ne sont plus utilis&eacute;es et qui n'ont pas fait l'objet d'une d&eacute;connexion de l'utilisateur
</td>

<td >
  Ce d&eacute;lai est le d&eacute;lai maximum utilis&eacute; lorsque l'applet Java envoie une requ&ecirc;te au serveur OPX2, si ce d&eacute;lai est expir&eacute; l'applet abandonne la requ&ecirc;te et envoie un message &agrave; l'utilisateur
</td>

<td >
  Ce d&eacute;lai est le d&eacute;lai maximum que le serveur doit attendre lorsqu'il envoie une requ&ecirc;te &agrave; l'applet JAVA. Si le d&eacute;lai est expir&eacute; le serveur abandonne la requ&ecirc;te en cours mais n'envoie pas de message &agrave; l'utilisateur. (si le d&eacute;lai est expir&eacute; cela signifie que la communication avec l'applet n'est plus possible)
</td>

<td >
  &nbsp;
</td>

<td >
  &nbsp;
</td>

<td >
  &nbsp;
</td>

2. 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

<span 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.