2010-03-20 9 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.

Problemi correlati