Implementación en caliente de un EAR de Java para minimizar o eliminar el tiempo de inactividad de una aplicación en un servidor.

deployment jboss (4)

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 que los usuarios permanezcan activos en la versión anterior? Usamos JBoss para el servidor de aplicaciones ...

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

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

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

se usó un enrutador inteligente como equilibrador de carga
la nueva versión se implementó en el 50% de los nodos del (nuevo) clúster
se entregaron nuevas conexiones estrictamente a estos nodos actualizados, los antiguos se balancearon entre 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, se implementó una nueva versión en nodos "antiguos" fuera de línea y se criaron como nuevos nodos
debido a la agrupación de EJB, las sesiones y los beans fueron recogidos por otros nodos antiguos
finalmente (en unas pocas horas), solo quedaba un nodo anterior, con una única instancia de la versión anterior y todos los clientes que usaban la versión anterior estaban conectados a él
cuando el último cliente anterior se desconectó, ese nodo fue derribado demasiado

Ahora, no soy un tipo de red, y no puedo darle muchos detalles (como qué era el hardware del enrutador y tal). Según tengo entendido, esto se puede configurar 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, entraría en conflicto con el anterior en los nombres JNDI).

Espero que ayude.

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

Desarrollar una nueva versión con nombres JNDI "versionados"; por ejemplo, si Cliente bean estaba bajo ejb / Cliente en la versión 1, en la versión 2 estaría bajo ejb / Cliente2
Tener una fachada comercial en la aplicación con una interfaz básica estable (Factory-style) que, cuando se le solicita Customer bean, intente encontrar el nombre JNDI con la versión más alta (no en cada llamada, por supuesto, puede guardar en caché durante una hora o así ) Esa fachada podría (y debería) desplegarse como una aplicación separada, y nunca o muy raramente actualizada
Ahora cada nuevo cliente tendría acceso a la última aplicación implementada, y las aplicaciones no entrarán en conflicto.

Este enfoque requiere una cuidadosa planificación y prueba, pero debe funcionar en mi humilde opinión.

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

Según tengo entendido, WebLogic tiene una función 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 implementó correctamente, 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

La sugerencia de Vladimir sobre el uso de un equilibrador de carga es una forma bastante segura de lograr lo que desea. Tenga en cuenta que no tiene que ser necesariamente un equilibrador de carga de hardware de alta gama. Por el contrario, si enfrenta 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 EAR.

// Nicholas