Domanda

    

Questa domanda ha già una risposta qui:

         

Stiamo assistendo a frequenti, ma intermittente errori java.net.SocketException: Connection reset nei nostri registri. Siamo sicuri di dove l'errore Connection reset è in realtà proviene, e come fare per il debug.

Il problema sembra essere correlato ai messaggi stiamo cercando di inviare. Si noti che il messaggio è non connection reset by peer.

Qualche suggerimento su quali potrebbero essere le cause tipiche di questa eccezione, e come potremmo procedere?

Ecco una traccia rappresentante dello stack (com.companyname.mtix.sms è il nostro componente):

    java.net.SocketException: Connection reset
        at java.net.SocketInputStream.read(SocketInputStream.java:168)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
        at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)
        at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
        at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1115)
        at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1832)
        at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1590)
        at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:995)
        at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
        at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
        at com.companyname.mtix.sms.services.impl.message.SendTextMessage.sendTextMessage(SendTextMessage.java:127)
        at com.companyname.mtix.sms.services.MessageServiceImpl.sendTextMessage(MessageServiceImpl.java:125)
        at com.companyname.mtix.sms.services.remote.MessageServiceRemoteImpl.sendTextMessage(MessageServiceRemoteImpl.java:43)
        at sun.reflect.GeneratedMethodAccessor203.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397)
        at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:186)
        at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323)
        at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
        at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
        at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
        at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453)
        at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
        at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
        at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at com.companyname.mtix.sms.http.filters.NoCacheFilter.doFilter(NoCacheFilter.java:63)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at com.companyname.mtix.sms.http.filters.MessageFilter.doFilter(MessageFilter.java:53)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:61)
        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.ajaxanywhere.AAFilter.doFilter(AAFilter.java:46)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)
    

La nostra componente è un applicazione web, in esecuzione con Tomcat, che chiama un terzo servizio Web parti che invia messaggi SMS, si dà il caso. La linea del nostro codice su cui l'eccezione si butta dal è l'ultima riga nel frammento di codice seguente.

String aggregatorResponse = null;
HttpClient httpClient = prepareHttpClient( username, password );
PostMethod postMethod = preparePostMethod( textUrl );

try {
  SybaseTextMessageBuilder builder = new SybaseTextMessageBuilder();
  URL notifyUrl = buildNotificationUrl( textMessage, codeSetManager );
  String smsRequestDocument = builder.buildTextMessage( textMessage, notifyUrl );
  LOG.debug( "Sybase MT document created as: \n" + smsRequestDocument );

  postMethod.setRequestEntity( new StringRequestEntity( smsRequestDocument ) );
  LOG.debug( "commiting SMS to aggregator: " + textMessage.toString() );
  int httpStatus = httpClient.executeMethod( postMethod );
È stato utile?

Soluzione

Il Javadoc per SocketException afferma che è

  

Thrown per indicare che v'è un errore nel protocollo sottostante come un errore TCP

Nel tuo caso sembra che la connessione è stata chiusa dal lato server della connessione. Questo potrebbe essere un problema con la richiesta che si sta inviando o un problema alla loro estremità.

Per aiutare il debug si poteva guardare utilizzando uno strumento come Wireshark per visualizzare i pacchetti di rete attuali. Inoltre, c'è un client alternativo per il codice Java che è possibile utilizzare per testare il servizio web? Se questo fosse successo, potrebbe indicare un bug nel codice Java.

Come si utilizza client HTTP Commons avere uno sguardo alla registrazione del client HTTP Comune Guida . Questo vi dirà come accedere alla richiesta a livello HTTP.

Altri suggerimenti

Questo errore di accade sul vostro lato e non l'altro lato. Se l'altro lato reimpostare la connessione, quindi il messaggio di eccezione dovrebbe dire:

java.net.SocketException reset by peer

La causa è la connessione all'interno HttpClient è stantio. Controllare il collegamento stantio per SSL non risolve questo errore. Soluzione:. Scaricare il client di e ricreare

Se si verifica questo cercando di accedere ai servizi Web distribuite in un server Glassfish3, si potrebbe desiderare di regolare le impostazioni http-thread-pool. Che SocketExceptions fisse che avevamo quando molti thread simultanei chiamava il servizio Web.

  1. Vai alla console di amministrazione
  2. Andare alla "Configurazioni" -> "Server config" -> "pool di thread" -> "http-thread-pool"
  3. .
  4. Cambio impostazioni "Max Discussione Pool Size" 5-32
  5. Cambio impostazioni "Discussione Min Pool Size" 2-16
  6. Riavvia Glassfish.

ho anche inciampare su questo errore. Nel mio caso il problema era che stavo usando JRE6, con il supporto per TLS1.0 . Il server supportato solo TLS1.2, quindi questo errore è stato gettato.

Nel mio caso, questo era perché mio Tomcat è stato impostato con un maxHttpHeaderSize insufficiente per un particolarmente complicato interrogazione SOLR.

Spero che questo aiuti qualcuno là fuori!

ottengo questo errore tutto il tempo e lo considero normale.

Succede quando un lato cerca di leggere quando l'altro lato ha riagganciato. Così a seconda del protocollo questo può o non può designare un problema . Se il mio codice client indica specificamente al server che sta per riagganciare, poi sia client che server possono riagganciare allo stesso tempo e questo messaggio non sarebbe successo.

Il mio modo di implementare il mio codice è per il cliente di appendere senza salutare. Il server può quindi catturare l'errore e ignorarlo. Nel contesto di HTTP, credo che un livello del protocollo permette più di una richiesta per connessione, mentre l'altro no.

In questo modo si può vedere come potenzialmente un lato poteva tenere appesa sull'altro. Dubito che l'errore si riceve è di alcuna preoccupazione piratesco e si potrebbe semplicemente prendere per evitare che si riempire il backup dei file di log.

Questo errore si verifica sul lato server quando il client ha chiuso la connessione socket prima che la risposta potesse essere restituito sopra la presa. In uno scenario di web app non tutti questi sono pericolosi, in quanto possono essere create manualmente. Ad esempio, smettere il browser prima che il reponse è stato recuperato.

L'eccezione indica che il socket è stato chiuso inaspettatamente dall'altro lato. Dal momento che si sta chiamando un servizio web, questo non dovrebbe accadere - molto probabilmente si sta inviando una richiesta che fa scattare un bug nel servizio Web.

Prova ad accedere l'intera richiesta in questi casi, e vedere se si nota qualcosa di insolito. In caso contrario, entrare in contatto con il fornitore di servizi web e inviare loro la richiesta problematica registrato.

So che questo thread è po 'vecchio, ma vorrei aggiungere i miei 2 centesimi. Abbiamo avuto lo stesso errore "Connection reset" a destra dopo la nostra una delle uscite.

La causa principale è stato, il nostro server apache è stato portato giù per la distribuzione. Tutto il nostro traffico di terzi passa attraverso apache e stavamo ottenendo il collegamento ripristinato errore a causa di esso che è in basso.

Questo è un vecchio thread, ma mi sono imbattuto in java.net.SocketException: Connection reset ieri.

L'applicazione lato server ha le sue impostazioni di limitazione modificate per consentire solo 1 connessione alla volta! Così, a volte chiamate ha attraversato e qualche volta no. Ho risolto il problema modificando le impostazioni di limitazione.

mi stavo esattamente questo errore troppo: Connection reset by peer. L'eccezione era stata sollevata da modello REST di primavera su eseguire il metodo postForObject(). Per me il problema era troppo a lungo richiesta URL HTTP. Quindi, in primo luogo verificare se l'URL prodotto è quello che dovrebbe essere e, se il server in realtà dovrebbe essere in grado di gestire le richieste di quella lunghezza, basta andare alla configurazione del server ed aumentare la lunghezza consentita di default di richieste di URL.

Che ha risolto il problema per me, ma essere consapevoli:. L'applicazione potrebbe non funzionare su alcuni browser Internet, specialmente quelli vecchi, come hanno fissa lunghezza massima di richieste di URL

Speranza che aiuta ...

Ho ottenuto questo errore quando il file di testo che stavo cercando di leggere conteneva una stringa che corrisponde una firma antivirus sul nostro firewall.

FWIW, mi è stato sempre questo errore quando stavo per caso facendo una richiesta GET a un endpoint che si aspettava una richiesta POST. Presumibilmente era solo in quel modo particolare i server di gestire il problema.

mi è stato sempre questo errore perché la porta ho provato a connettersi a era chiuso.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top