2010-11-23 28 views
5

He estado jugando con las nuevas funciones de asincronía de Servlet 3.0 con Tomcat 7.0.4. Encontré este Chat Application, que permite a los clientes esperar la solicitud GET para recibir actualizaciones de mensajes. Esto está funcionando bien cuando se trata de recibir los mensajes.Cómo saber si el cliente ha cerrado la conexión

El problema surge cuando el cliente se desconecta, es decir, el usuario cierra el navegador. Parece que el servidor no levanta IOException, aunque el cliente se haya desconectado. El hilo del mensaje (ver el código fuente del enlace de arriba) está escribiendo felizmente a todos los flujos de salida almacenados de AsyncContext.

¿Es esto un error de Tomcat? o me estoy perdiendo algo aquí? Si esto no es un error, ¿cómo se supone que debo detectar si el cliente ha cerrado la conexión?

Respuesta

1

El código de allí a la línea 44 - 47 se encarga de eso,

} catch(IOException ex) { 
    System.out.println(ex); 
    queue.remove(ac); 
} 

Y también en este caso a 75 - 83, usando thingie tiempo de espera,

req.addAsyncListener(new AsyncListener() { 
    public void onComplete(AsyncEvent event) throws IOException { 
     queue.remove(ac); 
    } 

    public void onTimeout(AsyncEvent event) throws IOException { 
     queue.remove(ac); 
    } 
}); 

EDIT: Después de conseguir un poco más de conocimiento.

  1. Tomcat 7.0.4 todavía está en versión beta. Entonces, puede esperar tal comportamiento
  2. Intenté pero no puedo encontrar el método setAsyncTimeout() en el documento, ni here, ni here. Por lo tanto, creo que lo descartaron por completo en la versión final debido a una razón válida desconocida
  3. El ejemplo indica "por qué debería usar el marco en lugar de esperar Servlet 3.0 Async API". Que deduce que está escrito antes de la cosa final

Entonces, lo que puedo decir, después de combinar todos estos hechos, es que estás tratando de trabajar con lo que está roto en cierto sentido. Esa también, puede ser, la razón de resultados diferentes y extraños.

+0

Bueno, eso se encargaría si la operación de escritura elevara la IOException que no está sucediendo. Por lo tanto, puedes cerrar el navegador y nunca recibir esa excepción. Y el tiempo de espera es en este ejemplo de 10 minutos. Eso es mucho si tiene, digamos, cientos de clientes. – SS3

+0

Probé el código con Glassfish v3 y parece que puedo obtener el eventoError con Firefox, pero con IE no funcionará. Esto es muy extraño. – SS3

+0

@ SS3: Entonces, ¿podemos decir que no tiene problemas con Firefox? –

Cuestiones relacionadas