¿Implementar en caliente un EAR Java para minimizar o eliminar el tiempo de inactividad de una aplicación en un servidor?

Question

He oído que esto es lo que hace JavaRebel, pero ¿hay alguna otra buena manera de implementar una nueva versión de un EAR mientras se permite a los usuarios permanecer activos en la versión anterior? Usamos JBoss para el servidor de aplicaciones ...

Answer 1

No es lo que hace JavaRebel. JavaRebel (según la descripción) reemplaza en caliente las clases en la memoria. No es aceptable en el caso de las conexiones existentes al sistema, ya que las clases actualizadas pueden romper la lógica del cliente.

Una vez que una empresa para la que trabajaba tenía un problema similar, se resolvió de esta manera:

• se utilizó un enrutador inteligente como equilibrador de carga
• la nueva versión se implementó en el 50% de los nodos del (nuevo) clúster
• las nuevas conexiones se entregaron estrictamente a estos nodos actualizados, las antiguas se equilibraron entre los nodos antiguos
• los nodos antiguos se tomaron fuera de línea (uno por uno, para mantener el número de clientes por nodo dentro de los límites)
• al mismo tiempo, la nueva versión se implementó en la línea " antigua " nodos y fueron criados como nuevos nodos
• debido a la agrupación de EJB, las sesiones y los beans fueron seleccionados por otros nodos antiguos
• finalmente (en unas pocas horas), solo quedaba un nodo anterior, con una única instancia de la versión antigua y todos los clientes que usaban la versión antigua estaban conectados a ella
• cuando el último cliente antiguo se desconectó, ese nodo también fue derribado

Ahora, no soy un tipo de redes, y no puedo darte muchos detalles (por ejemplo, cuál era el hardware del enrutador y demás). Entiendo que esto se puede configurar de manera bastante fácil, excepto que, si recuerdo bien, tuvimos que configurar un dominio Weblogic adicional para implementar nuevas versiones de la aplicación (de lo contrario, estaría en conflicto con el anterior en los nombres JNDI).

Espero que ayude.

P.S. Ichorus proporcionó un comentario que dice que la aplicación se implementa en los servidores de los clientes. Por lo tanto, el truco del enrutador puede no ser factible. Ahora, solo veo una solución viable en este momento (ahora son las 21:52, puedo pasar por alto las cosas :)) -

• Desarrolle una nueva versión con " versionado " Nombres JNDI; p.ej. si el bean Cliente estaba bajo ejb / Cliente en la versión 1, en la versión 2 estaría bajo ejb / Cliente2
• Tenga una fachada comercial en la aplicación con una interfaz básica estable (estilo Factory) que, cuando se le pregunta al cliente Bean, intenta encontrar el nombre JNDI con la versión más alta (no en cada llamada, por supuesto, puede almacenar en caché para un hora más o menos). Esa fachada podría (y debería) implementarse como una aplicación separada, y nunca o casi nunca se actualizará
• Ahora, cada nuevo cliente tendrá acceso a la última aplicación implementada y las aplicaciones no entrarán en conflicto.

Este enfoque requiere una planificación y prueba cuidadosas, pero debería funcionar en mi humilde opinión.

Recientemente modifiqué algunas aplicaciones de manera similar para permitir que coexistan en el mismo dominio (antes de usar el mismo nombre JNDI para diferentes fuentes de datos).

Answer 2

Según tengo entendido, WebLogic tiene una característica llamada implementación paralela para eliminar el tiempo de inactividad durante la actualización de la versión EAR. Puede implementar la nueva versión sin detener la aplicación existente y una vez que la nueva versión se haya implementado con éxito, puede cambiar de forma transparente de la anterior a la nueva.

No estoy seguro de si otro servidor de aplicaciones lo admite.

Ref: http://edocs.bea.com/wls/docs100/deployment/redeploy.html#wp1022490

Answer 3

La sugerencia de Vladimir sobre el uso de un equilibrador de carga es una forma bastante segura de lograr lo que quieres. Tenga en cuenta que no necesariamente tiene que ser un equilibrador de carga de hardware de gama alta. Más bien, si frente a su servidor JBoss con un servidor web nativo (Apache o IIS) y mod_jk o mod_proxy, puede mantener una fachada web común e implementar las rutinas de carga y enrutamiento aplicables en el momento de la actualización de EAR.

// Nicolás

Answer 4

Creo que es posible que desee examinar Spring utilizando el marco OSGI. http://www.springframework.org/osgi