2011-01-10 8 views
7

Sto utilizzando Jersey 1.4, la classe ApacheHttpClient e Apache MultiThreadedHttpConnectionManager per gestire le connessioni. Per lo HttpConnectionManager, ho impostato staleCheckingEnabled su true, maxConnectionsPerHost su 1000 e maxTotalConnections su 1000. Tutto il resto è predefinito. Siamo in esecuzione in Tomcat e facciamo connessioni a più host esterni utilizzando il client Jersey.Socket in CLOSE_WAIT da Jersey Client

Ho notato che dopo un breve periodo di tempo inizierò a vedere i socket in uno stato CLOSE_WAIT associati al processo Tomcat. Alcuni monitoraggi con tcpdump mostrano che gli host esterni sembrano chiudere la connessione dopo un po 'di tempo ma non si chiudono da soli. Di solito ci sono alcuni dati nella coda di lettura del socket, spesso 24 byte. Le connessioni utilizzano https e i dati sembrano essere crittografati, quindi non sono sicuro di cosa sia.

Ho controllato per essere sicuro che gli oggetti ClientRequest che vengono creati siano chiusi. Le prese in CLOSE_WAIT sembrano essere riciclate e non stiamo esaurendo le risorse, almeno in questo momento. Non sono sicuro di cosa stia succedendo sui server esterni.

La mia domanda è, è normale e dovrei essere preoccupato?

Grazie,

John

+0

Posso vedere qualche codice? Ho appena sentito parlare di questo e vorrei vedere come hai configurato MultiThreadedHttpConnectionManager in Jersey ... – markthegrea

+0

Spiacente, non posso pubblicare il codice. –

risposta

1

Questa è probabile che sia un dispositivo come il firewall o la sincronizzazione server remoto la sessione TCP. È possibile analizzare cattura dei pacchetti di HTTPS utilizzando Wireshark come descritto sulla loro pagina di SSL:

http://wiki.wireshark.org/SSL

La bandiera staleCheckingEnabled emette solo il controllo quando si va utilizzare effettivamente la connessione in modo che non si sta utilizzando risorse di rete (TCP sessioni) quando non sono necessari.