Application java caprecieuse

Programmation
#1

Bonjour, je ne sais pas si je suis dans la bonne catégorie tant il y a de paramètres dans mon soucis.
Déjà je suis admin réseau/système avec aucune connaissance en développement.

Pour se mettre dans le contexte:
Les développeurs de chez moi planchent sur une appli permettant de “webiser” une application Gcos via convertigo.
Mon rôle est de mettre en place toutes la partie d’accès à cette appli.

Premièrement, un serveur sous Debian avec tomcat et Jre pour faire tourner convertigo (et l’appli de mes développeurs).
Par la suite un deuxième serveur identique.
Ensuite un serveur toujours sous Debian avec apache2/mod_jk et load-balancing pour la redirection sur les serveurs tomcat.
Jusque là pas de soucis j’accède à la page par défaut d’apache , aux pages des serveurs tomcat (directement via le port 8080 et en passant par apache/mod_jk) ; le load-balancing marche aussi.

Le problème en lui-même :
Les connexions à l’application de mes développeur fonctionnent mais c’est l’application en elle-même qui ne marche pas.
Pour tester j’ai monté un serveur tomcat sous windows 2003 server.
Voici les différents tests et résultats:

  • Accès direct à l’application (tomcat 8080 sous debian) -> NOK
  • Accès direct à l’application (tomcat 8080 sous Windows) -> OK
  • Accès à l’application via Apache (mod_jk et direction vers tomcat Debian) -> NOK
  • Accès à l’application via Apache (mod_jk et direction vers tomcat WINDOWS) -> NOK

En gros, j’ai l’impression que dès que linux intervient (attention je ne suis pas partisan de BILL) dans la chaîne à quelque niveau que ce soit le problème survient.

Les messages d’erreurs sont les suivants : “TransactionTimeoutException : the transaction 'Default Transaction- has been interrupted because it did not terminate quickly enough” ou “unable to connect the session”

Merci par avance des différents éclairages que vous pourrez apporter, tant la source du problème reste floue pour moi.

#2

Tu vas voir les développeurs et tu leur demande pourquoi ils n’ont pas gérer les exceptions:

  • TransactionTimeoutException : the transaction 'Default Transaction- has been interrupted because it did not terminate quickly enough"
  • “unable to connect the session”

En travaillant avec eux, tu résoudras plus facilement le problème. Cette exception à une origine qui peut être très variée. Ce qui est sûr, c’est qu’ils ont compilés l’appli sachant pertinement qu’ils laissaient passer quelque chose.

Ensuite est-ce que la Debian et Windows utilisent la même version du JRE.

Les développeurs l’ont écrit avec l’obligation de faire du Java portable?
exemple: ‘.’ en place de ‘’ ou ‘case sensitivity’ gérée

#3

Merci pour ta réponse.

Les versions de tomcat sont les dernieres de apache : 6.0.14 pour Debian et 6.0.16 pour winwin.
Coté JAVA identique pour les deux : 1.6.0_03

#4

bonsoir,
je vois pas trés bien ce dont parle Cassius …
Un interet de java, et que, à version égale, tout ce que ce langage permet à un développeur d’écrire, est compréhensible par toute machine où java est installée … me gourgze-je ?

#5

quote="usinagaz"
Un interet de java, et que, à version égale, tout ce que ce langage permet à un développeur d’écrire, est compréhensible par toute machine où java est installée … me gourgze-je ?[/quote]
Théoriquement, non. Sauf que comme d’habitude, ça dépend aussi de la machine java, du niveau d’ajustement au matériel, et de la config de la machine sur laquelle tourne les servlets.

#6

bonsoir,
mais java ne fais pas que des servlets ;.
de plus, c’est côté serveur, dans ce cas, donc peu importe la version client de java.

#7

Ben oui: un servlet, ce n’est pas du java qui s’execute sur un serveur ?
C’est bien là que ce situe le pb, non ?

#8

Oui c’est côté serveur. Mais ceci:

me laisse dubitatif …

#9

C’est justement parceque le java en servlet peut dépendre de l’OS ou des composants qui le font tourner qu’il faut trouver comme le dit cassius ce qui dans le code est spécifique à java/tomcat sous iis.

#10

Il tourne sur JRE? GIJ? cacao? sablevm? jamvm? …

#11

Ca, c’est coté client me semble t’il, et c’est tomcat qui fait office de machine java, non ?
Or là, le pb se situe niveau serveur.

#12

[quote=“mattotop”]Ca, c’est coté client me semble t’il, et c’est tomcat qui fait office de machine java, non ?
Or là, le pb se situe niveau serveur.[/quote]
C’est aussi bien côté client que serveur. Après touts ces VM ne sont pas forcément capables d’exécuter des servlets, ou ont un niveau de compatibilité suffisant avec la norme J2EE ou autre qui font que Tomcat et tout le bazard ne peuvent s’exécuter. Mais ici, ce genre de question ne se pose pas vu que la personne à l’origine du thread a spécifié qu’ils utilisent la VM de Sun en version 1.6

Et non ce n’Est pas Tomcat qui fait tourner la VM, Tomcat s’appuie sur la VM qu’on lui indique (ou qu’il trouve) pour s’exécuter et exécuter le code Java qu’on lui demande d’interpréter (Servlet, JSP et tout le toutim).

Mon avis sur la question serait plus comme l’a dit cassius de commencer par voir au niveau de l’application ce qui cause les exceptions retournées et y’a des chances que ça donne une piste sur ce qui se passe. Ou peut être aussi un défaut de configuration dans le firewall qui permet les connexions entrante mais bloque dans l’autre sens ?

#13

en gros faut voir les sources du soft :slightly_smiling: