2010-03-20 12 views
8

Ho un'applicazione con architettura client server. Il client utilizza Java Web Start con Java Swing/AWT e il sert utilizza il server/servlet HTTP con Tomcat. La comunicazione viene effettuata dalla serializzazione di oggetti, crea un oggetto serializza una matrice di byte e invia al server rispettivamente chiamato ObjectInputStream e deserializza.java.net.SocketTimeoutException: lettura scaduta

L'applicazione segue la comunicazione corretta a un determinato tempo di concorrenza in cui inizia a mostrare l'errore "Timeout lettura SocketException". L'erro si verifica quando il server richiama il metodo ObjectInputStream.getObject() nel mio metodo doPost servlet.

Il tomcat arriverà lentamente e gli errori inizieranno a diminuire il tempo di risposta del server fino al tempo di arresto in cui devo riavviare il server e dopo che tutto funziona.

Qualcuno ha superato questo problema?

Codice 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(); 

Codice Server

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

parameters = input.readObject(); 

input.readObject() è dove l'errore è

+0

Potresti postare del codice? – Enrique

+0

È un parametro tcp linux? Come la dimensione del mem del buffer, i file aperti massimi o altro? –

+0

La quantità di tempo che trascorre prima di SocketException 20 minuti o più? (Se richiamo la quantità di tempo standard che un socket tcp/ip aspetterà prima che scada se non ci sono attività di connessione)? Dopo che tutta l'eccezione sta dicendo "timeout di lettura" potrebbe anche avere qualcosa a che fare con la natura asincrona del web? – Wintermut3

risposta

10

Non ci ha dato molte informazioni per andare avanti, soprattutto di il lato client. Ma il mio sospetto è che il lato client è:

  • non riuscendo a impostare l'intestazione Content-Length (o l'impostazione al valore errato),
  • non riuscendo a svuotare il flusso di output, e/o
  • non chiudendo il lato di uscita della presa.

misterioso.

In base alla tua domanda aggiornata, sembra che nessuno dei precedenti. Qui ci sono un paio di altre possibilità:

  • Per qualche motivo il lato client si blocca completamente durante la serializzazione o richiede un MOLTO TEMPO.
  • C'è un proxy tra il client e il server che causa problemi.
  • Si verificano problemi di rete relativi al carico o problemi hardware di rete.

Un'altra possibile spiegazione è che avete una perdita di memoria, e che il rallentamento è causato dal GC prendendo sempre più tempo, come si esegue fuori la memoria. Questo verrà visualizzato nei log del GC se sono abilitati.

0

Penso che durante la concorrenza elevata, il Timeout socket impostato in Tomcat sia scaduto e la connessione sia chiusa. La prossima lettura di Tomcat per quella connessione è maggiore del timeout del socket del server specificato nel server.
Se si desidera evitare questo problema, è necessario aumentare il timeout sul lato server che è scaduto nel caso. Ma non consigliabile.
BTW non hai dato abbastanza informazioni. Hai aumentato il numero di thread per la connessione in Tomcat? Se lo facessi, sicuramente sarebbe successo.