Discussion :

[Battosaiii]

Bonjour,

Sur un site de production, le batch java ne se termine pas.
Le dernier log fait référence à une librairie itext suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Table tabInfo = new Table(5);
tabInfo.setBackgroundColor(new Color(219,219,219));

Si on enlève les lignes précédentes, le programme ne se termine pas avec le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
tabInfo.setBorderColor(new Color(0, 0, 0));

A priori il semble y avoir un problème avec l objet Color ou les fonctions utilsant l' objet Color.

Nous utilisons itext 1.4.5 avec java 1.5 sur une machine HP-UX.
Ce programme ne fait pas appel a de serveur web.
Le batch fait un appel de ce style :

java -classpath $CLASSPATH fr.prog.MonProgramme $argument

Quels logs peut on demander à la prod pour comprendre ce problème ?

Merci

[NoClassDefFound]

Est-ce que ce programme utilise du log4j par exemple pour gérer les logs ou est-ce que les logs sont redirigées via la ligne de commande ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
java -classpath $CLASSPATH fr.prog.MonProgramme $argument > prog.log

Une erreur possible serait que la librairie awt n'existe pas sur le serveur, mais dans ce cas là tu aurais un plantage et pas un blocage.
Quand tu dis que le programme ne se termine pas, est-ce que tu sous-entends que le batch en question est multi-threadé ou dépend d'une ressource externe ?

[Battosaiii]

Les logs sont redirigés avec log4j.
Le dernier log est toujours sur une ligne lié à la classe java java.awt.Color.


Le batch java se bloque. Au début nous pensons à un while qui ne se termine pas dans le code, or le problème vient d'un blocage au niveau de manipulation de l objet Color.

SI on supprime tous les objets Color du code , le problème disparait.
Le batch java se termine alors. Est ce que ce problème peut être lié à leur machine HP-UX ?

On a testé sur une machine HP-UX mais on n'a pas reproduit le problème avec le même code.
Quels logs peux t on demandé au client pour avoir plus d infos?

[NoClassDefFound]

Cela a bien l'air d'être lié à awt, peut être un problème de jdk.
Est-ce que la machine en question dispose d'une carte graphique ?
J'utilises Birt dans une de mes applications et j'ai été obligé de mettre l'option -Djava.awt.headless=true dans les paramètres de démarrage de la JVM sur notre serveur RedHat.
Cette option lui indique de tenter d’utiliser les librairies graphiques natives même en l’absence d’environnement graphique.

[tchize_]

Est ce que ce problème peut être lié à leur machine HP-UX ?

Houuuu, ça me rappelle de sales souvenirs la AWT + HPUX.

En un mot, oui, tout problème bizarre et m****iques en java peux être lié à HP UX


Première question: ton application dispose-t-elle d'un environnement graphique? Si non, tu dois démarrer ton java en mode headless

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

java -Djava.awt.headless=true ton.Main

Autre chose, je dis ça, je dit rien. HPUX fournis ses propres jvm. T'as un code qui merde dès que tu utilise color sur leur OS. C'est des serveur qui coutent bonbon au carré.... Ca fait jamais de tord d'aller réveiller leurs hotline de support (Moi j'ai quitté le serveur HPUX pour un problème similaire après 6 mois d'aller / retour avec leur hotline)

[Battosaiii]

Merci

Effectivement cette option "java -Djava.awt.headless=" marche chez le client!
En revanche je n'ai pas trouvé trop d infos sur l'info "java.awt.headless". Y a il une documentation expliquement clairement qu il faut une carte graphique pour utiliser java.awt ?

[tchize_]

une carte graphique, non, mais un environnement graphique, oui. java.awt, ce sont des librairies destinées à l'affichage sur un bureau. 80% du code de ces librairies nécessite donc un bureau. Pour les 20% restant, le mode headless leur permet de fonctionner malgré l'absence de bureau. Par exemple, les Font ne feront pas de tentative de détection du DPI (ce qui n'a pas de sens sans affichage), pas de correction de colorimétrie, etc.


Pour la doc, http://docs.oracle.com/javase/1.4.2/....html#headless

[Battosaiii]

Fausse alerte ! Vous pouvez ignorez mon message précédent. En effet le client semble avoir toujours le même problème avec -Djava.awt.headless. Je lui ai demandé de voir avec le support client mais à priori ca va pas se faire. Donc pour l'instant je continue à trouver d'autres solutions.

Il nétait pas en mesure non plus de nous dire si il y avait de carte graphique.
Le problème semble être apparu depuis le monter en version oias1013 et java 1.5.
Ce problème n'arrive pas sur nos environnement pour la même machine et oias1013 et java 1.5 .
Donc je ne sais toujours pas la nature du problème.

[tchize_]

Quand l'application givre, kill -3 sur le process et récupérer la sortie stdout de l'application java, elle contiendra un threaddump qui te permettra de savoir exactement où l'application se bloque (à l'intérieur de Color)