2010-03-12 11 views
13

Estoy buscando una pista sobre cómo hacer que tomcat CI esté listo o un contenedor de servlets/contenedor de aplicaciones que a menudo se vuelve a desplegar como ocurre cuando se usa hudson ci.¿Tomcat 6 está listo para la integración continua o cómo hacer que funcione?

Experimenté que Tomcat 6 no anula el despliegue de webapps, dejando las clases en jvm.

Por ejemplo Monitoricé Tomcat 6 con VisualVM: el inicio de clases 2000, el despliegue de una aplicación 3000 después de redeploy 4000 y volver a implementar las clases 5000 y así sucesivamente - que conduce a accidentes, pérdidas de memoria ...

esperanza Vale uno tiene una pista sobre Tomcat y la integración continua u otros servidores de aplicaciones.

+0

Me encantaría * ver las respuestas a esto también. Hemos tenido problemas similares con los errores de memoria de PermGen, etc. con nuestros autodeploramientos de CI a Tomcat 6. – Pete

+0

¿Está ejecutando la última versión de tomcat? Tiene más errores de registro en cuanto a lo que no se limpia correctamente en la recarga de contexto. Si usa mysql, obtenga el conector/j 5.1.12, ya que soluciona una fuga de subprocesos, lo que provoca grandes pérdidas de recarga en tomcat. – nos

+0

Utilizamos aplicaciones pequeñas sin mysql o conectores. Pequeñas aplicaciones de ejemplo de primavera, simples hello world jsp aps y más. – jpse

Respuesta

7

Actualización: He realizado algunas pruebas con una aplicación web moderadamente compleja utilizando Spring, Hibernate, GWT, C3P0 y hsqldb.

Stock Tomcat 6.0.24 funciona bien, siempre que utilice el compilador del cliente. Funciona en diez redespliegues, mientras que el compilador del servidor se divide en el cuarto. Te sugiero que pruebes con la bandera -client.

Intentar depurar el uso del compilador del servidor fue infructuoso, ya que el Eclipse MAT no mostró raíces GC para los cargadores de clases, y sin embargo se conservaron. Según informes, un insecto que se hace referencia frecuentemente, PermHeap bloat in and only in server VM se fijó en Java 6 Update 16, pero mis pruebas fallan con la actualización de Java 6 16.


Tomcat ha sido comprobado y una doble comprobación para este tipo de problemas de memoria, y muy a menudo la las aplicaciones tenían la culpa. No, eso no quiere decir que sea necesariamente difícil tener una fuga de gen tan permanente.

Hay dos posibilidades aquí:


Si realmente se desea depurar este problema y asegurarse de que la culpa es de Tomcat, puede que el Eclipse memory analyser. Tienen un buen blog post explaining how to debug PermGen problems.

+0

Hola, dijiste que GCC está roto ... ¿Qué quieres decir exactamente con eso? Hay alguna prueba? de todos modos, sí, de hecho la aplicación a menudo causa el problema, es por eso que utilizamos aplicaciones de ejemplo como las que usan millones de veces. La nueva característica de detección de fugas desafortunadamente no resuelve el problema, pero es un buen paso en la dirección correcta y ayuda a entender qué está pasando ... – jpse

+0

Sí, la referencia de GCC es bastante opaca, lo siento. Lo que quiero decir es que nosotros, como desarrolladores, tenemos la tendencia de culpar a otros componentes: servidor de aplicaciones, sistema operativo, rayos cósmicos :-) por problemas que no podemos explicar. Lo he hecho muchas veces, y casi siempre encuentro el error en mi código. –

+0

@Robert gracias por el enlace eclipse – jpse

1

siempre me gusta tomar medidas drásticas para asegurarse de que todo está limpio y en un estado totalmente reproducible cuando se inicia

1) matar a Tomcat

2) borrarlo del disco

3) descomprimir una versión limpia

4) sobrescribir los archivos configurados modificados personalizados

5) reiniciar Tomcat

6) desplegar su aplicación

+0

Gracias, hemos usado tomcat limpio nuevo para las pruebas, no se han aplicado retoques, eso no es exactamente el punto ... – jpse

+0

Si bien este es el enfoque "más seguro", también será mucho más engorroso de configurar, especialmente si tiene múltiples servidores Tomcat udpate por CI (dev, alfa, preproducción, etc.). ¿Por qué crees que estas medidas drásticas son necesarias (especialmente la reinstalación de Tomcat)? – sleske

-1

Eche un vistazo a Apache Cactus - es un marco para las pruebas de unidad en el contenedor del lado del servidor. Funciona prácticamente con cualquier contenedor de servlets.

+0

Aunque Apache Cactus es interesante, no veo cómo esto se relaciona con la pregunta, que trata sobre los problemas causados ​​por frecuentes redespliegues. – sleske

Cuestiones relacionadas