2010-03-20 18 views
8

Tengo una aplicación con arquitectura de servidor de cliente. El cliente utiliza Java Web Start con Java Swing/AWT y el sert usa el servidor HTTP/Servlet con Tomcat. La comunicación se realiza a partir de la serialización de objetos, crea un ObjectOutput serializa una matriz de bytes y la envía al servidor , respectivamente llamada ObjectInputStream y deserializa.java.net.SocketTimeoutException: tiempo de espera agotado

La aplicación sigue comunicando correctamente a un cierto tiempo de concurrencia donde comienza a mostrar el error "Tiempo de espera de lectura de SocketException". El error ocurre cuando el servidor invoca el método ObjectInputStream.getObject() en mi método servlet doPost.

El tomcat será lento y los errores comenzarán a disminuir el tiempo de respuesta del servidor hasta el momento del bloqueo donde debo reiniciar el servidor y después de que todo funcione.

¿Alguien ha tenido este problema?

Código Cliente

URLConnection conn = url.openConnection(); 
conn.setDoOutput(true); 

OutputStream os = conn.getOutputStream(); 
ObjectOutputStream oss = new ObjectOutputStream(os); 

oss.writeUTF("protocol header sample"); 

oss.writeObject(_parameters); 
oss.flush(); 
oss.close(); 

código del servidor

ObjectInputStream input = new ObjectInputStream(_request.getInputStream()); 
String method = input.readUTF(); 

parameters = input.readObject(); 

input.readObject() es donde el error es

+0

¿Podría publicar algún código? – Enrique

+0

¿Es un parámetro de tcp linux? Al igual que el tamaño de la memoria intermedia, max abrir archivos u otros? –

+0

¿La cantidad de tiempo que pasa antes de SocketException es de 20 minutos o más? (si recuerdo la cantidad estándar de tiempo que esperará un socket tcp/ip antes de que se agote el tiempo si no hay actividad de conexión)? Después de todo, la excepción le dice "tiempo de espera de lectura", ¿podría tener esto algo que ver con la naturaleza asincrónica de la web? – Wintermut3

Respuesta

10

No nos ha dado mucha información para seguir adelante, especialmente acerca el lado del cliente. Pero mi sospecha es que el lado del cliente es:

  • no poder establecer la cabecera Content-Length (o ajustarlo a un valor incorrecto),
  • no para eliminar el flujo de salida, y/o
  • no cerrando el lado de salida del zócalo.

misterioso.

Según su pregunta actualizada, parece que ninguna de las anteriores. Aquí hay un par de otras posibilidades:

  • Por alguna razón, el lado del cliente se bloquea por completo durante la serialización o tardando MUCHO TIEMPO.
  • Hay un proxy entre el cliente y el servidor que está causando problemas.
  • Tiene problemas de red relacionados con la carga o problemas de hardware de red.

Otra posible explicación es que usted tiene una pérdida de memoria, y que la desaceleración se debe a la GC tomando cada vez más tiempo a medida que se agota la memoria. Esto aparecerá en los registros del GC si los tiene habilitados.

0

Creo que durante la alta concurrencia, el tiempo de espera del socket configurado en Tomcat ha expirado y la conexión está cerrada. La siguiente lectura de Tomcat para esa conexión es mayor que el tiempo de espera del socket del servidor especificado en el servidor.
Si desea evitar este problema, tiene que aumentar el tiempo de espera en el lado del servidor que expiró en su caso. Pero no es aconsejable.
Por cierto, no proporcionó suficiente información. ¿Aumentó el número de hilos para la conexión en Tomcat? Si lo hicieras, seguramente esto pasaría.

Cuestiones relacionadas