Premier message d'erreur repéré dans le log de Tomcat (catalina.out) :

22 août 2008 09:08:24 org.apache.jk.common.MsgAjp processHeader
GRAVE: BAD packet signature 18245

Autre information non-négligeable, les utilisateurs n'arrivent pas à se connecter à l'application le matin et après la pause de midi.

Google a beau être notre ami, il n'apporte pas son aide précieuse cette fois-ci. Le seul conseil que l'on peut trouver est d'utiliser un vrai Tomcat. Bien que cette réponse ne soit pas entièrement dénuée de bon sens, elle ne répond en rien à la question.

Il va falloir lire la documentation du connecteur AJP et du workers.properties qui détaille la configuration de JK.

Vraisemblablement, il s'agit d'un problème avec un firewall placé entre le serveur frontal Apache et le serveur d'application Tomcat. Lorsqu'un utilisateur se connecte à l'application, et donc réalise une requête HTTP via son navigateur, un processus serveur Apache va traiter cette requête. La requête en question étant destinée au serveur d'application, Apache va la transmettre à Tomcat grâce à JK. Si elle n'existait pas déjà avant, JK va créer une connexion vers un connecteur AJP côté Tomcat. Et, dans le but d'optimiser les performances, cette connexion sera réutilisée par la suite pour traiter d'autres requêtes, évitant ainsi le coût de création d'un nouveau socket.

Le problème observé arrive quand il n'y a aucun utilisateur pendant une certaine période de temps, et donc aucune requête qui transite à travers la connexion AJP entre Apache et Tomcat. Le firewall, suivant sa configuration, va alors considérer la connexion comme coupée et la supprimer de ses tables de maintien de connexions sans rien dire à personne. Et, un peu plus tard, quand notre utilisateur sera rassasié ou aura bien dormi, il va "réveiller" cette connexion AJP et celle-ci sera tuée par le firewall.

La documentation de configuration de JK nous apporte la solution. Il faut positionner le paramètre socket_keepalive à true :

worker.nom_worker.socket_keepalive = true

La prochaine fois, nous irons un peu plus loin encore dans la configuration de JK, d'Apache et de Tomcat.