Discussion :

[flepretre]

Bonjour,

je travaillle sur un site intranet de monitoring d'une application de réservation sur un grand site internet français.

J'ai été impressionné par l'intégration de Netbeans et Glassfish, et comme beaucoup le disent, le résultat est une application commercial en open source.
Bien sur, je comprends que Sun est encore dans la découverte de petits problèmes.

Les fonctionnalités apportées sont pour moi très intéressantes (vérification et appels intégrés des EJB, Appli Swing en GUI ....) et je suis en train de migrer mon appli de Jboss 4.2 vers GlassFish V2.
cette application en intranet utilise JMS, entity, AJAX, JSF. Ce serveur est utilisée de manière intensive pour indiquer en temps réel les problèmes de notre réservation.

Ma configuration est WinXP, GlassFish V2.

Quelques programmes ont du être modifiés car SUN et plus stricte que JBOSS, ce qui est très positif.

La console ADMIN est fabuleuse comparé à la définition de JBOSS qui se limite à la modification des fichiers de config.

J'ai fait quelques modifications qui m'ont été nécessaires ...
Pour les connexion JMS, j'ai du modifier l'attribut
ON ANY FAILURE Close All Connections
De même pour la connexion JDBC.
En effet, si il n'y a pas deconnexion pour les JMS et EJB Entity, le serveur se bloque.

Mais, j'ai quelques problèmes plus complexes ....

1- La CPU passe à 100% sans raison logique. En mettant la verbosité de mon appli sur FINEST, je ne vois rien d'inhabituel pour mes programmes ....
De plus la logique Business fonctionne depuis 3 ans sur un serveur JBoss, donc je vois pas d'où vient ce pic de CPU, qui est constant.
Comment gérer ce pic de CPU ?
Je viens encore de l'avoir ce matin après avoir voulu relancer le domaine après un blocage. J'ai du tuer le thread et recréer le domaine.

2- Quand je dois arrêter le domain, il ne stoppe pas. La console ASADMIN STOP-DOMAIN attend une fin de job qui n'arrive pas.
Peut on forcer le stop domain ????
Ceci est un gros problème car à chaque nouveau test sur glassfish je dois réinstaller ...
J'ai remarqué un thread Java de 30Mb qui est présent et qui n'est pas le serveur ni l'appli Derby que j'utilise. Est-ce relié à JMS ?
Quand je dois tuer les process car l'appli est bloquée, en relançant le domaine, mon appli ne peut être chargée car il y a une exception:
2ff84288135;|java.lang.Exception: MQJMSRA_LB4001: start:Broker running at:localhost:7676 has a different var directory of:
D:\tools\glassfish\domains\domainMonitorTpf\imq:Failing ra.start()

--> Très grosse misère, car après ce message le domaine ne repart jamais !!!!!

Je dois réinstaller le domaine complet, mais c'est très lourd quand on teste.
Une méthode pour éviter ce style de problème serait je pense très utile.

Voilà ma situation, en ce moment tout tourne ok, mais comme ce serveur est utilisée de manière intense, j'attends de voir si je vais devoir tout réinstaller encore....

Mis à part ce problème de relance de domaine, les temps de réponse sont très supérieurs et la migration semble avoir été une bonne idée.

Franck

[flepretre]

J'ai une piste pour l'utilisation CPU.
Avec AJAX, j'appelle mon serveur GlassFish et j'extraie des pages.
A chaque fois, la securité est appelée dans la log.
j'ai plein de messages:

[#|2008-04-03T11:49:04.406+0200|FINE|sun-appserver9.1|javax.enterprise.system.core.security|_ThreadID=33;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=com.sun.web.security.WebSecurityManager;MethodName=hasUserDataPermission;_RequestID=0fa0f86f-0886-49a4-852b-d153043d8163;|[Web-Security] hasUserDataPermission isGranted: true|#]

[#|2008-04-03T11:49:04.406+0200|FINE|sun-appserver9.1|javax.enterprise.system.core.security|_ThreadID=33;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=com.sun.web.security.WebSecurityManager;MethodName=setPolicyContext;_RequestID=0fa0f86f-0886-49a4-852b-d153043d8163;|[Web-Security] Policy Context ID was: monitorApplication/monitor_war|#]

[#|2008-04-03T11:49:04.406+0200|FINE|sun-appserver9.1|javax.enterprise.system.core.security|_ThreadID=33;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=com.sun.web.security.WebSecurityManager;MethodName=hasResourcePermission;_RequestID=0fa0f86f-0886-49a4-852b-d153043d8163;|[Web-Security] hasResource isGranted: true|#]

[#|2008-04-03T11:49:04.406+0200|FINE|sun-appserver9.1|javax.enterprise.system.core.security|_ThreadID=33;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=com.sun.web.security.WebSecurityManager;MethodName=hasResourcePermission;_RequestID=0fa0f86f-0886-49a4-852b-d153043d8163;|[Web-Security] hasResource perm: (javax.security.jacc.WebResourcePermission /images/wok.gif GET)|#]

J'ai implémenté mon propre REALM, mais que puis je faire pour que mes images ne nécessitent pas un appel à la sécurité ?

Merci
Franck

[alexismp]

Quelle version précise de GlassFish utilises-tu?

Sur le problème de CPU à 100%:
Essaye de faire un "jstack" sur le process glassfish au moment du pic (ou monitoring avec jconsole).
Pourquoi ce besoin de re-créer le domaine (est-ce lié au problème JMS) ?
Pourquoi penses-tu que les appels à hasUserDataPermision sont bien liés au pic?

Pour le problème d'arrêt, même punition avec jstack. Je pense que pour l'instant il est plus important de comprendre pourquoi tu ne peux pas arrêter le serveur proprement.

Quel mode d'intégration GF/MQ utilises-tu? Peut-être une solution pour ton probleme JMS de (re)démarrage ici.

[flepretre]

Désolé pour la lente réponse.
Merci pour ces informations concernant JSTACK, J'ai pu repéré ce qui n'allait pas.

Il y avait une adaptation de Hibernate de JBOSS vers GLASSFISH V2UR1 qui était en erreur. Le code bouclait (d'ou les 100% de CPU) et je ne pouvais prendre la main.

Pau ailleurs, les temps de réponse de Glassfish sont nettement plus intéressants que Jboss dans les premiers tests effectués. La migration vers glassfish peut être finalisée.

[alexismp]

Merci pour le suivi. As-tu une référence pour le problème Hibernate? Si d'autres tombes dessus...

[flepretre]

En fait, je n'ai rien rajouté comme information sur ce problème de CPU car ce n'était qu'un problème dû à mon code.

Je bouclais sur un entityManager.remove(), une boucle avait été modifiée et celle-ci avait une mauvaise condition de fin de boucle.

La difficulté a été de trouver laquelle de mes requêtes JMS était responsable!