Merci à Obutterlin , je suppose qu'il s'agit du même problème. Simplement, entre-temps nous avons progresser dans l'investigation.
J'essaie de reformuler la situation :
- Notre application en test est développée avec les frameworks EJB3 – Struts1. Elle doit fonctionner dans un serveur d'application JBoss-4.2.3 avec jdk6.10 sous OpenSuse sur une machine virtuelle VMWare. La base de données est hébergée sur un AS400 en V5R3M0.
- La configuration par défaut du serveur JBoss default n'a été modifiée que sur les points suivants :
login-config.xml pour l'authentification et l'autorisation propre à l'application;
jboss-service.xml pour augmenter le timeout de la transaction
le rajout de commons-net-1.4.1.jar et jakarta-oro-2.0.8.jar pour faire le FTP et jt400.jar comme connector vers DB2/400
le ear de l'appli et ses 2 xxx-ds.xml (car on a 2 Persistence Units)
- Tout a bien marché en environnement de développement et de test (JBoss est démarré sous Eclipse)
- Notre soucis commencent au jour où l'on voulait basculer en mode pré-prod, c-à-d, démarrer JBoss depuis le console Linux du serveur VMWare. La fonctionalité qui merde est vraiment basique : Dans un Stateless Session Bean, on lit un fichier csv et traite les données ligne par ligne dans une boucle. Avant la fermeture de l'accolade de for, j'appelle la méthode entityManager.persist(entity). Au bout d'un certain nombre d'insertion, plantage pour cause de format de données (forcément, puisqu'il y a un décalage). On a essayé aussi un VMWare avec Windows Serveur 2003, c'est pareil. Par contre, sur un vieux serveur (lent) avec Red Hat, ça tourne bien, jamais de plantage. Je ne sais pas si c'est à cause de Hibernate, de JDBC, du réseau, de 400,
Si qq'un a une idée, ...
Merci
Partager