Discussion :

[JefDeBourges]

Pour ma part nous sommes sous weblogic 6.1.

Le moins que je puisse dire c'est qu'il ne faut pas avoir besoin du support de BEA

Notre appli en est à son 2ème coup de chaud.
La 1ère fois, nous étions en 6.1sp1. l'expert BEA après avoir accusé notre appli s'est retranché derrière un bug de la jvm sun
Et encore, il a creusé son "diagnostic" car en stressant la même appli déployée sous Tomcat ca tenait
Nous nous en sommes sorti en passant en 6.1sp5 et en pluguant la jirokit de la v7.

La 2nde fois (en ce moment), un autre "expert" est venu et devinez quoi ? Il accuse à nouveau l'appli....
Si encore il étayait en nous disant c'est telle ou telle partie qui provoque des dead-locks, mais non !! Il a juste constaté que tous les threads étaient en wait et hop la phrase magique "c'est pas WLS ca vient d'ailleurs"

Si notre appli était complexe, je comprendrais....mais non, de simples jsp/servlets (avec struts en framework), un chouïa de SGBD (SQLServer), des connecteurs telnet (Scort) pour revamper des transactions CICS.

Les symptômes ? Au bout d'une 40aine de minutes de test de stress, on observe une surconsommation mémoire puis tout ce gèle... Les threads wls se mettent en wait, IIS empile les requêtes HTTP et le CICS se la coule douce.

Bref, ca pue le bug dans les processus internes (wls et jvm), une saturation de la mémoire permanente ou un blocage du garbage

Moralité : si pas besoin d'aide, pourquoi pas weblogic

PS : A ceux qui demanderaient pourquoi on ne passe pas en wls8.1 (ou websphere ou jboss ou autre), je leur conseillerai d'aller bosser qq jours dans un grand groupe pour découvrir ce qu'est un urbaniste technique, un architecte technique, une centrale d'achat....

[XavierZERO]

Bonjour à tous,

J'ai lu l'ensemble de vos mails et certains m'ont été très utiles pour en apprendre plus. J'ai l'impression que ma question annodine à lancer un genre de trolls sur ce Forum.

Je pense qu'il est toujours intéressant de laisser cette question ouverte car de nombreux visiteurs l'ont consulté et elles restent toujours d'actualité. Alors je vous invite à rajouter vos nouvelles expériences sur les serveurs d'applications, des comparaisons de serveurs voire vos propres benchmark maison.

Merci à tous les membre pour votre participation active à ce sujet de discussion.

[Medo_free]

Et qu'en est-il des solutions Open? telles que JBoss, Jonas, OpenEJB.

Est-ce une solution fiable et viable?
Quelqu'un les as-il utilisé en production?
Y a t-il des comparatifs entre des serveurs open source et commerciales?

Pour ma part, je sais que le grand défaut des serveur open est la documentation, elle est affreuse et si on veux la doc officielle de JBoss il faut la payer (nouveau buissnes plan de Jboss?), donc un gros point noir pour ce genre de serveurs.

De plus on remarque le nombre de serveur d'appli J2EE proliférer, quelle est leur place dans un créneau déjà chargé?

Voilà mes question!

Merci.

[XavierZERO]

Perso, je connais un peu JBoss et JOnAS.

Des deux, je préfère JOnAS parce qu'il respecte mieux la norme EJB et est plus ouvert que JBoss du fait qu'il soit développé par un consortium. D'ailleurs JOnAS représente une brique logicielle du serveur d'application Red Hat Enterprise Server.

Tu peux trouver un bonne doc de JOnAS en plus de celle sur l'objectweb.
http://jonas.objectweb.org/doc/jonas...jonas3.3.6.pdf

Pour les benchmarks, j'ai rien trouver là-dessus de récent mais perso je n'ai pas vu de grosses différences.

[Medo_free]

Ce que je peux te dire de JOnAS et de JBoss est le suivant:

J'ai trouvé JOnAS plus difficile d'accès, avec une documetation un peu brouillon, il faut aussi générer les classes intermédiaires (les stub et les skeltons,etc...) à l'aide de l'outil GenIC.

Pour Jboss, je l'ai trouvé plus "domptable" que JOnAS, du le dézipe, rajoute un jboss.xml à ton ejb-jar et ça marche 5 min après chrono en main!

De plus je te parle pas du temps de démarrage de Jboss presque instantanement(Remarquable surtout sur les petites configs).

[RanDomX]

JBoss est une alternative fiable et viable.

JBoss à été le premier conteneur d'EJB validé par Sun pour la spec 1.4 de J2EE.

Jonas est très bien aussi mais plus diificile à prendre en main.

@+

[request]

JBoss à été le premier conteneur d'EJB validé par Sun pour la spec 1.4 de J2EE.

Tu es sure qu'il a été cértifié?

[RanDomX]

hummm, certifié je sais pas, mais validé oui. Mais il me semble:

ATLANTA—November 18, 2003—JBoss Group LLC today announced it has reached
an agreement with Sun Microsystems, Inc. to license the J2EE 1.4 technology
compatibility kit to certify the industry’s most popular open source, Java™-based
application server, JBoss®. JBoss Group is testing its product with Sun’s J2EE 1.4
Compatibility Test Suite (CTS), a suite of tests, tools and documentation that provides a
standard way of testing an implementation for compatibility with the J2EE specification,
thus demonstrating the company’s commitment to the J2EE value proposition of choice,
flexibility and compatibility.

Depuis c'est bon il me semble, je l'ai lu je ne sais plus ou...


extrait complet:
http://www.jboss.org/services/press/j2eecert.pdf

[request]

J'ai rien trouvé sur leur site, ils ne mettent pas en avant leur certification

Pourtant ton info existe bien

J'y comprends pas grand chose...

[knotty]

Quand ils disent "jboss commits to j2ee specs", ca veut dire que Jboss va tout faire pour devenir j2ee.

Ils sont arrive a une entente "cordiale" avec Sun sur le sujet. c'est a dire que Sun est d'accord pour leur faire une remise (sur le prix)

Mais le travail n'est pas fait. Il y a beaucoup de boulot pour que Jboss soit compliant. Peut etre la version 4, a voir.

[fdouilly]

Pour le choix d'un application server il est également très important de bien appréhender l'ensemble de l'architecture cible.

SI vous avez à adresser du Tuxedo, les connecteurs sont déjà présents sous Weblogic, ce qui n'est pas le cas dans Websphere ou d'autres. Un temps de développement supplémentaire sera nécessaire pour avoir des connecteurs ad hoc.

Idem côté IBM qui fournit en standard maintenant un WSIF pour les accès CICS.

Enfin si l'on se tourne vers des solutions de portails, de mobilités, il faut connaitre les offres des éditeurs au dessus de leur Application Server.

Tout ca pour préciser qu'il ne faut pas se cantonner aux AS.

See u.

Frédéric DOUILLY

[Chahid]

je te conseille cet article ceci te donnera un idée sur ton choix
http://www.jroller.com/page/trom/20040425#why_we_choosed_jonas_instead

[piedsvelus]

Pour ma part nous sommes sous weblogic 6.1.

Le moins que je puisse dire c'est qu'il ne faut pas avoir besoin du support de BEA

Notre appli en est à son 2ème coup de chaud.
La 1ère fois, nous étions en 6.1sp1. l'expert BEA après avoir accusé notre appli s'est retranché derrière un bug de la jvm sun
Et encore, il a creusé son "diagnostic" car en stressant la même appli déployée sous Tomcat ca tenait
Nous nous en sommes sorti en passant en 6.1sp5 et en pluguant la jirokit de la v7.

La 2nde fois (en ce moment), un autre "expert" est venu et devinez quoi ? Il accuse à nouveau l'appli....
Si encore il étayait en nous disant c'est telle ou telle partie qui provoque des dead-locks, mais non !! Il a juste constaté que tous les threads étaient en wait et hop la phrase magique "c'est pas WLS ca vient d'ailleurs"

Si notre appli était complexe, je comprendrais....mais non, de simples jsp/servlets (avec struts en framework), un chouïa de SGBD (SQLServer), des connecteurs telnet (Scort) pour revamper des transactions CICS.

Les symptômes ? Au bout d'une 40aine de minutes de test de stress, on observe une surconsommation mémoire puis tout ce gèle... Les threads wls se mettent en wait, IIS empile les requêtes HTTP et le CICS se la coule douce.

Bref, ca pue le bug dans les processus internes (wls et jvm), une saturation de la mémoire permanente ou un blocage du garbage

Moralité : si pas besoin d'aide, pourquoi pas weblogic

PS : A ceux qui demanderaient pourquoi on ne passe pas en wls8.1 (ou websphere ou jboss ou autre), je leur conseillerai d'aller bosser qq jours dans un grand groupe pour découvrir ce qu'est un urbaniste technique, un architecte technique, une centrale d'achat....

Je rigole en lisant ce message car je travaille depuis 1 an sur 4 applis web JSP/Struts/EJB Session + JDBC sur du Weblogic 8.1. Nous rencontrons les mêmes difficultés.

Sur la dizaine de postes de developpement Windows (PIV avec 512Mo minimum) Weblogic part régulièrement en OutOfMemory que se soit avec la jrockit ou la jvm de sun fourni avec (1.4.1). Solution : utiliser la jvm 1.4.2 même si elle n'est pas certifiée ou monter à 1Go de RAM. Ca réduit de bcps les incidents.
Eviter la sp2 c'est encore pire, Weblogic refuse carrement de démarrer dans certains cas...

Les benchs effectués sur des machines identiques production conduisent dans des conditions extrèmes de stress à un plantage en 2 heures avec la même raison : sur-consomation mémoire et un garbage collecteur qui ne s'en sort plus.

Sur les serveurs de production on observe après qq heures d'utilisation intensive des fuites mémoires qui provoquent la mort du serveur. Après avoir réglé qq problèmes liés à l'utilisation de log4j et devant la persistence des fuites mémoires et des OutOfMemory des serveurs nous avons fait intervenir un consultant BEA qui après 2 semaines d'examen de notre configuration et de nos applications à préconisé la chose suivante :
-2 ou 3 serveurs quadri-processeurs avec 4Go de RAM par application ,
-redemarrage journalier des machines

bref surdimensionner l'architecture pour permettre à l'ensemble de fonctionner correctement. Cependant cela n'empeche pas les plantages des serveurs et cela même si 1 seul des 4 processeurs est utilisé et que on ne depasse pas 400 utilisateurs par serveur ...

J'ai en outre remarqué que c'est souvent lors de la phase de deploiement des EJBs ou après une phase prolongée d'inactivité (quant il s'agit de depassiver les EJBs) que Weblogic avait tendance à planter.
Autre remarque : la console de monitoring de la mémoire de Weblogic provoque egalement une forte consomation mémoire et pour peu que l'on choisise un taux de rafraichissement trop élevé on peut planter weblogic uniquement par le fait de faire fonctionner la console d'administration (qui est une appli web je le rapelle)...

[wace]

nous avons fait intervenir un consultant BEA qui après 2 semaines d'examen de notre configuration et de nos applications à préconisé la chose suivante :
-2 ou 3 serveurs quadri-processeurs avec 4Go de RAM par application ,
-redemarrage journalier des machines

HIHIHIHIHI je rigole bien parce que j'ai du intervenir chez un client sur la validation de l'arci technique et c'est a peu pres ce que je leur ai dit de faire ( Heuuu je bosse pas pour BEA mais svt en partenariat avec eux )

sauf ke j'ai fait des preco de ouf pour une fois ke j'etais a peu pres sur que ca passerait
une appli pour 300 users max et < 100 tres gourmant en ressource en cluster
c'etait du genre
25 utilisateur simultanées max par CPU
4 Go par serveur ( multi processeur il me semble )
redemarrage machine journalier
et deviné quoi .... l'expert BEA qui est passé apres pour faire la validation coté client a dit qu'il n'y avait pas besoin de redemmarrer les machines que WLS n'en avait pas besoin .... et le mec qui a dit ca est l'expert N°1 de reference de BEA en Europe

[Tueur_a_gage]

Ce topic commence à vieillir.... plus personne n'a de retour d'expérience à faire partager ?

Pour ma part j'ai utiliser WebLogic 6 et 8, WebSphere 5.1, un peu JBoss et Jonas que je suis en train de regarder.

WebLogic est super bien, mais super cher et super lourd..... pas besoin de redémarrage particulier, mais il faut dire que la charge n'est pas si importante que cela (30 users)

WebSphere c'est plus compliqué, je n'ai utilisé que WASD, pas de verrsion standalone, et c la catastrophe (poste pas assez costaud ?) plantage, out of memory et j'en passe pour un user => moi

Jboss pas assez d'utilisation pour en parler si ce n'est que je trouve l'interface d'admin on ne peut plus pauvre, du coup pas forcément simple à utiliser (via Eclipse peut-être pour se simplifier la chose)

Jonas m'a l'air sympa, console admin ok (weblogic look & feel), qq plantage dans le redéploiement d'ear (version 4.5 ?) mais surtout gratuit.... mon soucis tient-il la charge ?

D'après certaines rumeurs (FT R&D) c'est pas terrible pour la charge un bon vieux Weblogic fait mieux l'affaire. C'est sur une Mercedes est forcément mieux qu'une Clio, mais la vitesse est limitée maintenant ? pour des applications de type PME avec une charge soutenue mais raisonnable (ou se trouve la limite ?), Jonas ne serait-il pas largement suffisant évitant ainsi un surcout des licences Weblo et WebSphere ?

a+ pour de nouvelles contributions......

[alexismp]

Ce topic vieillit mais ne meurt pas! ;-)
Il y a désormais un nouveau serveur full-J2EE Open Source: GlassFish.
Il s'agit de la mise dans l'Open Source du serveur d'application de Sun (version 8.1).
Qq explications ici: http://blogs.sun.com/roller/page/ale...try=glassfish1

[sse]

Bonne info, mais :

- De quelle taille est l'équipe dédiée au projet ?

- Cette mise en Open Source étant faite, Sun va-t-il continuer d'intervenir de manière active sur ce projet ?

- Les forums et autres sont-ils actifs ?

- Aviez vous utilisé auparavant l'AppServeur de Sun ?
- Si oui, retour d'expérience ?

- Avez vous utilisé GlassFish ?

[alexismp]

Les réponses de l'architecte de GlassFish sont ici: http://blogs.sun.com/roller/page/ale...fish1#comments

[spiralcb]

Et sinon, personne n'a utilisé Geronimo?

[zolive]

Concernant Geronimo il sert de base a la version du serveur d'app de Websphere d'IBM la Community Edition.

Autre détail égualement JBoss n'est pas le seul serveur D'app certifiee par SUN : JOnAS l'est aussi depuis quelques temps (cf : jonas.objectweb.org )
Il est en version 4.6.6 est a pas mal évolué depuis que certain du forum l'on utilisé (à l'époque en version 3.3...)
Pour ma part je l'utilise et il me convient parfaitement. Ils sont entrain d'implementer la spec EJB3 attendu pour la version 5 il me semble. Pour les EJB3 JBoss semble être en avance car je crois qu'ils ont enormement participé à l'élaboration de la spec en s'appuyant sur le framework de persistance d'Hibernate et la derniere spec de JDO2