Vale la pena actualizar a JBoss 7.1 desde JBoss 5.1

Question

Actualmente nuestro entorno de producción ejecuta JBoss 5.1 y hemos estado debatiendo si vale la pena migrar a JBoss 7.1. Si fuera una simple actualización del servidor, entonces no sería un problema. Pero, desafortunadamente, tendríamos que cambiar las configuraciones y eso requeriría un poco de esfuerzo. Además, nuestro servidor se ejecuta en un clúster y leo que JBoss 7.1 tiene más soporte de clúster.

¿Vale la pena o no?

Gracias

Answer 1

Estamos actualmente en la misma situación.

Parece que hay un un montón de cosas por el lado positivo:

• Vamos a tener que migrar fuera de 5,1 en un punto. Necesitamos un perfil completo y no hay tantas alternativas de OSS (GlassFish y tal vez Geronimo). Ese punto solo probablemente venderá la migración ya que PCI-DSS nos prohíbe usar software EoL'd.
• La configuración es mucho mejor y más simple. Ya no está distribuido en más de 20 archivos XML en los que se configuran los aspectos en archivos XML, pero un lugar central. Todos los puertos están configurados en un lugar central, ya no existe un archivo XSL que transforma server.xml. Puede dar sentido al archivo de configuración sin conocer los detalles de implementación de las clases. Es difícil apreciar esto si nunca has configurado un JBoss.
• El EJB remoto ya no usa un hilo por socket.
• Eliminar un subsistema que no necesita es mucho más fácil.
• El modelo de carga de clases se ve en forma y se obtiene un gran control a través de jboss-deployment-structure.xml
• La biblioteca del cliente EJB parece mucho más limpia. Se han reducido a 10 JAR de 20, la mitad de ellos incluso paquetes OSGi (nuestro cliente es una aplicación Eclipse RCP).
• Si bien no estamos demasiado entusiasmados con Java EE 6 reemplazando algunos de nuestros SLSB con @Singleton beans y algunos de nuestros SAR con temporizador EJB sin duda parece interesante.
• Inicio más rápido y menos uso de memoria (al menos para un servidor vacío o pequeñas implementaciones). Todavía no hemos probado una implementación grande.
• La carpeta despliegues está vacío por defecto

cosas que todavía tenemos que mirar en:

• Estamos un poco preocupados por el rendimiento Infinispan. Actualmente usamos la API TreeCache de JBoss Cache. Si bien hay un adaptador para Infinispan que proporciona la misma API, algunas pruebas teóricas muestran un peor rendimiento de escritura. Esto solo se aplica al árbol API de Infinispan.
• ExternalContext ya no es compatible, actualmente utilizamos para rellenar un árbol JNDI de un archivo de .bindings
• consola JMX se ha ido, si tiene algo que se basa en este necesita ser adaptada, Editar hay en realidad, un puerto de JMX-Console disponible AS7-2227

No corremos en un clúster así que no puedo comentar sobre eso.

Lo que probablemente sea el mayor esfuerzo para nosotros es migrar todos los scripts de shell (instalación, pruebas de integración, ...) que interactúan de una forma u otra con JBoss.

actualización

Nos han emigrado y fue sin duda vale la pena. Algunas actualizaciones de los puntos anteriores:

• Incluso las implementaciones grandes son rápidas con mínimas cantidades de ajuste.
• El registro centralizado (Slf4j, JUL, JCL, Log4j, ...) es realmente agradable.
• 7.1 tiene tantos errores que era inutilizable para nosotros, entonces estamos en 7.2/EAP 6.1 y planeamos ir a 7.3/EAP 6.2. Todavía tiene su parte justa de errores pero podemos evitarlos. Estamos especialmente ansiosos por el control de acceso basado en roles para la interfaz de administración que nos permitirá ejecutar nuestros scripts con privilegios mínimos.
• No habrá una versión compatible de GlassFish 4 que ponga un gran signo de interrogación sobre ella para uso en producción.
• La seguridad remota de EJB es mucho menos flexible. Tuvimos que poner algunas soluciones ya que anteriormente estábamos mezclando llamadas EJB autenticadas y no autenticadas, esto ya no es posible.
• El JEE 6 BOM POM de JBoss es una bolsa mixta. En teoría, es bueno porque administra las versiones de todas las dependencias de JEE. En la práctica, las coordenadas son horribles con la versión en el artifactId, que será molesto cuando migremos a JEE 7. Además, no es muy útil cuando se desea incluir una implementación de una API JEE para las pruebas.
• El rendimiento del árbol Infinispan API no fue un problema.
• Reemplazamos las secuencias de comandos de la consola JMX con scripts DMR.

Actualización 2

• Hay una deadlock al utilizar la comunicación remota de EJB a través de SSL. Este punto muerto está presente incluso en EAP 6.2. Ahora estamos en el punto en que tenemos un conjunto de características de parche respaldado de WildFly a AS 7.

Answer 2

¿Funciona todo en JBoss 5.1.0 para usted? ¿Es tu rendimiento algo con lo que puedes vivir?

Actualmente estoy en medio de la actualización de JBoss 5.1.0GA a JBoss 7.1.1 y no ha sido nada fácil. Básicamente, estás actualizando a un nuevo servidor de aplicaciones. Necesitarás presupuestar una gran cantidad de dólares para este esfuerzo, supongo.

Habiendo dicho que JBoss 7.1.1 es MUY rápido en comparación con 5.1.0 (tiempos de arranque al menos). Creo que en los próximos 6 meses (más o menos) la mayoría de los problemas de transición y migración "dura" se verán concretados en los foros de jboss o mediante la corrección de errores. En ese momento, usted y su equipo pueden volver a evaluar si desea realizar la migración.

¡Buena suerte!

Answer 3

Si está utilizando SSL, una de las ventajas de la actualización es que JBoss 7.1.1 se ejecuta en jdk 1.7, que tiene soporte para TLS 1.1 & 1.2, mientras que jdk 1.6 solo admite hasta TLS 1.0. JBoss 5 no se ejecutará en Java 1.7 por lo que eres susceptible a un ataque BEAST.

Answer 4

En cualquier caso, esperaría un poco.

AS 5 es un servidor EE5, AS 7.1 es un servidor EE6 (y la especificación EE6 salió en 2009). Así que eso es mucho trabajo para un excelente nuevo entorno de tiempo de ejecución, pero no le dará ninguna posibilidad de arquitectura caliente.

El WildFly 8.0.0.CR1 ya se debe y es el servidor EE7 que le ofrece un conjunto de nuevas posibilidades de desarrollo interesantes, como WebSockets y JAX-RS 2.0 (http://www.slideshare.net/dandreadis/2013-11devoxxwild-flybof). Nuevas funciones de administración, como parche de instancia única. Y no es seguro que AS7-a-WildFly8 sea una migración súper fácil ya que se introducen algunas cosas nuevas importantes, como Undertow en lugar de JBossWeb/Tomcat.

Si tienes que irte, tienes que irte, y si U te llevas por la ruta 7.x muerta, no te olvides de ponerle las manos a la muy mejorada etiqueta 7.2.0.Final (varios cientos de problemas mejor que 7.1 .1). Pero si crees que puedes comenzar a desarrollar/migrar ahora usando versiones Beta/CR y esperar unos meses para una versión estable de producción de WildFly 8.x.x, es posible que puedas quedarte sentado más tiempo antes de la próxima actualización importante.

br, Jens