Home > Thuest > Plan de despliegue para thuest 0.2

Plan de despliegue para thuest 0.2

September 30th, 2009 chechu Leave a comment Go to comments

En la versión 0.2 de thuest se han introducido algunos cambios que han complicado un poco el despliegue. Recordemos que contamos con un servidor glassfish con un clúster que tiene asociada una instancia, sólo tenemos una máquina :-)

Los cambios en la nueva versión a los que me refería son básicamente la actualización a Grail 1.2-M2, con su nueva gestión de dependencias transitivas con ivy (que te trae más mierda de la que necesitas) y el uso de JMS mediante el plugin de grails.

Los pasos que sigo para desplegar son:

  1. chechu$> grails clean. Limpio.
  2. chechu$> grails get-dependencies. Me traigo todas las dependencias configuradas con ivy.
  3. chechu$> sudo cp lib/xercesImpl-2.9.1.jar /opt/glassfish/lib; sudo cp lib/postgresql-8.3-603.jdbc4.jar /opt/glassfish/lib. Estos JARS los necesita la aplicación, pero colocarlos en el PATH del servidor ha sido la mejor forma con la que he conseguido que todo funcione.
  4. chechu$> rm lib/xercesImpl-2.9.1.jar. Dejar este JAR en la aplicación entraba en conflicto con el servidor y lo dejaba inestable totalmente.
  5. Edito el fichero .grails/1.2-M2/projects/theq/plugins/jms-0.5-RC2/src/groovy/grails/jms/listener/ListenerConfig.groovy e indico que no quiero asociar a los listener JMS que se creen automáticamente un gestor de transacciones. Para ello eliminio la línea 125 (transactionManager = ref(”transactionManager”)).
  6. chechu$> grails war. Empaquetar.

Por otro lado preparo el servidor glassfish:

  1. Elimino el despliegue anterior desde la consola web de glassfish.
  2. Paro el dominio y el agente que gestiona la instancia
  3. root$> rm -rf /opt/glassfish/nodeagents/agent1/instance1/applications/j2ee-modules/thuest-*. Elimino los restos de despliegues anteriores.
  4. root$> killall java. Mato los procesos java que queden (con cuidado de que no tenga otras cosas de Java corriendo)
  5. root$> ps aux | grep java. Me aseguro de que no queda nada corriendo de java, ni el imqbrokerd.
  6. root$> asadmin start-node-agent agent1. Arranco el agente que gestiona la instancia.
  7. root$> asadmin start-domain thuest. Arranco el dominio.
  8. Creo los recursos JDBC y JMS. Para la connectionFactory de JMS me aseguro de que la opción Transaction Support está a NoTransaction. También me aseguro de asignar el target correcto para todos los recursos.
  9. Reinicio el clúster (lo paro y lo arranco), para que acceda a la nueva configuración. Para todo por completo si es necesario.
  10. Despliego la aplicación

Ficheros de logs interesantes:

  • /opt/glassfish/nodeagents/agent1/instance1/logs/server.log. El destino del log de la aplicación
  • /opt/glassfish/nodeagents/agent1/instance1/config/stacktrace.log. Donde se vuelcan las excepciones de la instancia 1.
  • /opt/glassfish/nodeagents/agent1/instance1/imq/instances/myclusterinstance1/log/log.txt. El log del broker de JMS arrancado por glassfish internamente.
Categories: Thuest Tags:
  1. September 30th, 2009 at 14:40 | #1

    Qué burro, asesinando a todos los nodos, a pelo además. ¿Por qué no lo haces en caliente? Yo con Glassfish redespliego siempre desde la consola web sin problemas.

    Es que cuando tengas miles de usuarios…. ¿qué harás? ¿los echarás a todos?

  2. September 30th, 2009 at 17:24 | #2

    Cuando tenga miles de usuarios espero no tener que andar redesplegando yo la aplicación, porque eso de tener que convertirte cada día en el master del universo en un tema concreto agota. Este finde ha sido Glassfish, los clúster y JMS; hace unos meses me convertí en el master en RAID para formatear el disco duro del servidor; la semana pasada el máster en OAuth para la integración con twitter… que te voy a contar

  1. No trackbacks yet.