- Serveur ?
Tomcat 6
- Usage (Site Internet/Intranet ? B-to-B /EAI ? Intégration de données) ?
Applications Intranet
- Nombre d'utilisateurs/sessions ?
pouvant atteindre 1200 utilisateurs parfois.
- Topologie (serveur standalone, cluster horizontal, vertical, grille ?)
stand-alone
- Composants spécifiques utilisés (EJB, JMX, JMS, etc...)
rien de spécifique.
- Motivations de son choix ?
Plusieurs raisons, mais principalement :
- Démarrage rapide, ce qui augmente la productivité au dév.
- Pas gourmand en ressources
- Supporte une charge importante.
- Niveau de satisfaction ?
Très staisfaits. Ca tourne depuis plus de 2 mois en prod sans la moindre défaillance grave.
- Problèmes rencontrés
-logs pas assez précis/riches
- Rapports d'erreurs pas aussi bons qu'ils pourraient l'être : il arrive que Tomcat refuse de déployer une application sans qu'il affiche la raison précise (depuis le manager) (qui s'était avérée être un NCDFE).
- Médiocre support Linux out-of-box.
- Motivations de son abandon futur ?
Rien à voir en particulier avec Tomcat, mais plutôt avec l'architecture des applications Java EE : pas assez flexible pour répondre à des besoins qu'on a.
Par exemple, on bosse sur un client en Eclipse RCP, qui grâce à le modèle de plug-ins d'Eclipse peut être configuré/personnalisé à mort sans toucher au code.
Or, ce client utilise ds services deployés sur un serveur, qui doit en principe être aussi configurable/malléable ... pas très évident à faire dans l'étant actuel des choses.
- En cas d'abandon, au privilège de quel serveur ou type de serveur ?
SpringSource Application Platform à priori.
Partager