2011-11-02 27 views
28

Tengo una aplicación hello, world servlet con la que estoy jugando, y la envío a mi servidor Tomcat en un VPS.Cómo depurar la memoria caché de tomcat cuando se implementa un nuevo archivo .war? ¿Hay una configuración de configuración?

Cuando realizo un cambio en mi código y lo despliego, tomcat no sirve el código recién publicado (incluso después de volver a iniciar el servicio).

Detengo el servicio, luego inserto el nuevo archivo de guerra en/webapps /, y me aseguro de eliminar también la carpeta antigua explotada.

Cuando reinicio el servidor, todavía sirve la antigua base de código.

¿Hay alguna configuración en la configuración para detener este comportamiento?

Además, ¿qué carpetas tendría que eliminar? Sea específico (carpetas y rutas) ya que he intentado eliminar algunos y no he llegado a ningún lado.

+0

¿Tomcat está apuntando al mismo directorio donde está publicando el archivo war? Si eliminó la versión explotada (supongo que el directorio de trabajo) y reinició el servidor, no puedo pensar en cómo Tomcat tendría acceso al código anterior. Por favor, revise su server.xml de cerca. – aishwarya

Respuesta

12

Puede eliminar el directorio "trabajo".

¿Estás seguro de que no es un problema de caché del navegador?

+0

Sí, estoy seguro, incluso eliminé la carpeta de trabajo/catalini/localhost (o alguna carpeta como esa), ha sucedido un par de veces no es casualidad :) – Blankman

+0

Eliminar cosas en los directorios de tomcat no afectará necesariamente la memoria caché del navegador –

+0

y la nueva versión estaba escribiendo registros en un archivo, e intenté con Firefox (estaba usando chome primero) – Blankman

0

Parece que su cargador de clases no está cargando las clases de servlet una vez que se actualizan. Esto podría solucionarse si cambia su archivo web.xml, que debería solicitar al servidor/contenedor que vuelva a implementar y vuelva a cargar las clases de servlet. Supongo que agrega una línea vacía al final de su web.xml y guárdela y luego vea si eso la soluciona. Como dije, esto podría solucionarlo o no.

¡Buena suerte!

+0

No debería persistir durante un reinicio después de la eliminación completa de la versión anterior. –

+0

Hmm, sí. Normalmente no debería, pero vale la pena intentarlo. – Mechkov

1

Parece un problema de marca de tiempo. De acuerdo con la documentación de tomcat, si hay un nuevo jsp o servlet esto creará un nuevo archivo _java en la carpeta de trabajo a menos que los archivos _java.class sean más nuevos que jsp o servlets.

1

Tomcat también crea un directorio ROOT en el mismo nivel que work/. ROOT/ también almacena en caché las cosas viejas. elimine ROOT junto con el directorio Catalina en work.

4

Yo agregaría que en caso de un comportamiento realmente extraño, donde pasa un par de horas diciendo WTF, intente borrar manualmente el directorio /webapps/yourwebapp/WEB-INF/classes. Un archivo fuente java que se movió a otro paquete no tendrá su archivo de clase compilado eliminado, al menos en el caso de una aplicación web explotada en TC. Esto puede enloquecerlo gravemente con un comportamiento impredecible, especialmente con un servlet anotado.

2

Un poco tarde a la fiesta, así es como lo hago

  1. aplicación Undeploy del gestor de
  2. Tomcat apagado utilizando ./shutdown.sh
  3. Borrar la caché del navegador
  4. Eliminar la aplicación de aplicaciones web, y desde /work/Catalina/...
  5. Tomcat de inicio usando ./startup.sh
  6. Copie la nueva versión de la aplicación en /webapps y enciéndala.
0

Tengo un mal momento para poner mi archivo war en /etc/tomcat7/webapps pero la ruta real era /var/lib/tomcat7/webapps. Puede usar sudo find/-type f -name "my-war-file.war" para saber dónde está.

Y elimine estas carpetas /tmp/hsperfdata_* y /tmp/tomcat7-tomcat7-tmp.

2

me encontré con un comportamiento extraño que no reflejaba la base de código real así que después de algún tiempo de probar varias soluciones, mi problema fue solucionado eliminando manualmente todo bajo /var/cache/tomcat8/

+0

En mi caso, el cargador de clases estaba encontrando una clase inexistente que, más tarde, no pudo cargar. El problema era un archivo .class obsoleto almacenado en/var/cache/tomcat6/... –

0

que tenía el mismo problema dos veces, pero en la segunda Cuando me di cuenta de que no era un problema para Tomcat, intente eliminar el caché de su navegador, actualice la página y vea si se muestra la nueva versión de la página en su servidor. Funcionó conmigo

0

Soy nuevo en Tomcat, y este problema me estaba volviendo loco hoy. Fue esporádico Le pedí ayuda a un colega, y la GUERRA se expandió y lo hizo como se suponía que debía. 3 se implementa más tarde ese día, volvió a la versión original.

En mi caso, el MySite.WAR se amplió a ROOT Y MySite. MySite usualmente se sirve. Pero a veces Tomcat decidió que le gustaba ROOT mejor y todos mis cambios desaparecieron.

La "solución" es eliminar el sitio web ROOT con cada despliegue de la guerra.

Cuestiones relacionadas