2009-04-20 8 views
5

Estoy ejecutando una aplicación web J2EE en Tomcat, y recientemente se me ha encomendado la tarea de agregar métricas a la aplicación. Estoy usando un SessionListener para detectar cuándo se destruye la sesión y luego subir las métricas a una base de datos. El tiempo de espera de mi sesión se establece en mi web.xml a 30 minutos, y no estoy invalidando la sesión en ningún lugar mediante programación. A menudo, durante el período de 1 5 a 10 minutos de mi inicio de sesión para la prueba, veré 3 o 4 conjuntos de métricas cargados en la base de datos, todos con identificaciones de sesión diferentes.Invalidación de sesión aleatoria

Además de web.xml y session.invalidate(), ¿qué otra cosa puede causar que se destruya una sesión en Tomcat? Excepciones? ¿Alguna vez Tomcat invalidará aleatoriamente las sesiones?

+0

¿Utiliza sesiones persistentes? – trunkc

+0

No estoy usando sesiones persistentes. – jconlin

+0

Su registro debe crear solo una sesión, mencionó que crea 3 o 4. ¿Mantiene las métricas solo cuando se destruye la sesión o también cuando se crea? –

Respuesta

4

Posiblemente su navegador web haya decidido no enviar la cookie de sesión a una solicitud a la aplicación web, donde su aplicación habría esperado una. He visto esto suceder con una regla de reescritura de Apache; una URL fuera de la ruta de la cookie de sesión se redirigió a la aplicación web. Hay algo así como los folowing ocurrido (detalles pueden ser malo):

  • mi aplicación web se encuentra en/app/
  • así la cookie de sesión estaba destinada a esta ruta/app/
  • una página en el WebApplication refiere a /img/magic.jpeg
  • el navegador no envía la cookie de sesión en su solicitud de esta imagen (ruta no se han encontrado)
  • el servidor redirige la petición (internamente) a/app/createImage? mágica
  • la web la aplicación no recibió una cookie de sesión, por lo que creó una nueva sesión

Debería poder ver si esto causa su problema si registra la URL inicial para nuevas sesiones.

0

Esto probablemente no es lo que está sucediendo en su servidor, pero si la hora del sistema se establece en el servidor, esto puede provocar que las sesiones expiren más rápido que un "tiempo transcurrido" de 30 minutos. Tomcat, al menos a partir de 5.5, utilizó el "tiempo de reloj" para caducar las sesiones, por lo que cambiar el reloj del sistema afectará la duración de la sesión.