是什么导致了我的 java.net.SocketException:连接重置?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/585599/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-11 16:32:46  来源:igfitidea点击:

What's causing my java.net.SocketException: Connection reset?

javasocketssocketexceptionconnection-reset

提问by Richard Ev

We are seeing frequent but intermittent java.net.SocketException: Connection reseterrors in our logs. We are unsure as to where the Connection reseterror is actually coming from, and how to go about debugging.

我们java.net.SocketException: Connection reset在日志中看到频繁但间歇性的 错误。我们不确定Connection reset错误实际上来自哪里,以及如何进行调试。

The issue appears to be unrelated to the messages we are attempting to send. Note that the message is notconnection reset by peer.

该问题似乎与我们尝试发送的消息无关。请注意,该消息不是connection reset by peer

Any suggestions on what the typical causes of this exception might be, and how we might proceed?

关于此异常的典型原因可能是什么以及我们如何进行的任何建议?

Here is a representative stack trace (com.companyname.mtix.smsis our component):

这是一个代表性的堆栈跟踪(com.companyname.mtix.sms是我们的组件):

    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)
    


Our component is a web application, running under Tomcat, that calls a third party Web service that sends SMS messages, it so happens. The line of our code on which the exception gets thrown from is the last line in the code snippet below.

我们的组件是一个 Web 应用程序,在 Tomcat 下运行,它调用发送 SMS 消息的第三方 Web 服务,它就是这样发生的。抛出异常的代码行是下面代码片段中的最后一行。

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

采纳答案by Mark

The javadoc for SocketException states that it is

SocketException 的 javadoc 指出它是

Thrown to indicate that there is an error in the underlying protocol such as a TCP error

抛出表示底层协议有错误,如TCP错误

In your case it seems that the connection has been closed by the server end of the connection. This could be an issue with the request you are sending or an issue at their end.

在您的情况下,连接的服务器端似乎已关闭连接。这可能是您发送的请求的问题或他们的问题。

To aid debugging you could look at using a tool such as Wiresharkto view the actual network packets. Also, is there an alternative client to your Java code that you could use to test the web service? If this was successful it could indicate a bug in the Java code.

为了帮助调试,您可以使用诸如Wireshark 之类的工具来查看实际的网络数据包。另外,是否有替代 Java 代码的客户端可用于测试 Web 服务?如果此操作成功,则可能表明 Java 代码中存在错误。

As you are using Commons HTTP Client have a look at the Common HTTP Client Logging Guide. This will tell you how to log the request at the HTTP level.

当您使用 Commons HTTP Client 时,请查看Common HTTP Client Logging Guide。这将告诉您如何在 HTTP 级别记录请求。

回答by Michael Borgwardt

The Exception means that the socket was closed unexpectedly from the other side. Since you are calling a web service, this should not happen - most likely you're sending a request that triggers a bug in the web service.

异常意味着套接字从另一端意外关闭。由于您正在调用 Web 服务,因此不应发生这种情况 - 很可能您发送的请求会触发 Web 服务中的错误。

Try logging the entire request in those cases, and see if you notice anything unusual. Otherwise, get in contact with the web service provider and send them your logged problematical request.

在这些情况下尝试记录整个请求,看看您是否注意到任何异常。否则,请与 Web 服务提供商联系并将您记录的有问题的请求发送给他们。

回答by Paul

This error occurs on the server side when the client closed the socket connection before the response could be returned over the socket. In a web app scenario not all of these are dangerous, since they can be created manually. For example, by quitting the browser before the reponse was retrieved.

当客户端在通过套接字返回响应之前关闭套接字连接时,服务器端会发生此错误。在 Web 应用程序场景中,并非所有这些都是危险的,因为它们可以手动创建。例如,在检索到响应之前退出浏览器。

回答by Paul

This error happens on your sideand NOT the other side. If the other side reset the connection, then the exception message should say:

这个错误发生在你身边,而不是另一边。如果对方重置了连接,那么异常消息应该是:

java.net.SocketException reset by peer

The cause is the connection inside HttpClientis stale. Check stale connection for SSL does not fix this error. Solution: dump your client and recreate.

原因是内部连接HttpClient陈旧。检查 SSL 的陈旧连接不能修复此错误。解决方案:转储您的客户端并重新创建。

回答by Gorge

I get this error all the time and consider it normal.

我一直收到此错误并认为这是正常的。

It happens when one side tries to read when the other side has already hung up. Thus depending on the protocol this may or may not designate a problem. If my client code specifically indicates to the server that it is going to hang up, then both client and server can hang up at the same time and this message would not happen.

当另一侧已经挂断时,一侧试图阅读时会发生这种情况。因此,根据协议,这可能会或可能不会指定问题。如果我的客户端代码专门向服务器指示它要挂断,那么客户端和服务器都可以同时挂断并且不会出现此消息。

The way I implement my code is for the client to just hang up without saying goodbye. The server can then catch the error and ignore it. In the context of HTTP, I believe one level of the protocol allows more then one request per connection while the other doesn't.

我实现我的代码的方式是让客户不说再见就挂断电话。然后服务器可以捕获错误并忽略它。在 HTTP 的上下文中,我相信协议的一个级别允许每个连接超过一个请求,而另一级别则不允许。

Thus you can see how potentially one side could keep hanging up on the other. I doubt the error you are receiving is of any piratical concern and you could simply catch it to keep it from filling up your log files.

因此,您可以看到一侧可能会继续挂断另一侧。我怀疑您收到的错误是否属于盗版问题,您可以简单地捕获它以防止它填满您的日志文件。

回答by Roquen

I was getting exactly that error too: Connection reset by peer. The exception was being raised by Spring's REST template upon running the postForObject()method. For me the problem was too long HTTP URL request. So first check whether the URL produced is what it should be and, if your server really should be able to handle requests of that length, simply go to server's configuration and raise the default allowed length of URL requests.

我也遇到了那个错误:Connection reset by peer. Spring 的 REST 模板在运行该postForObject()方法时引发了异常。对我来说,问题是 HTTP URL 请求太长。所以首先检查生成的 URL 是否应该是它应该是的,如果你的服务器真的应该能够处理那个长度的请求,只需转到服务器的配置并提高 URL 请求的默认允许长度。

That solved the problem for me, but be aware: the application might not run on some internet browsers, especially old ones, as they have fixed max length of URL requests.

这为我解决了问题,但请注意:该应用程序可能无法在某些 Internet 浏览器上运行,尤其是旧浏览器,因为它们具有固定的 URL 请求的最大长度。

Hope it helps...

希望能帮助到你...

回答by P?lOliver

If you experience this trying to access Web services deployed on a Glassfish3 server, you might want to tune your http-thread-pool settings. That fixed SocketExceptions we had when many concurrent threads was calling the web service.

如果您在尝试访问部署在 Glassfish3 服务器上的 Web 服务时遇到这种情况,您可能需要调整 http-thread-pool 设置。当许多并发线程调用 Web 服务时,我们遇到了固定的 SocketExceptions。

  1. Go to admin console
  2. Navigate to "Configurations"->"Server config"->"Thread pools"->"http-thread-pool".
  3. Change setting "Max Thread Pool Size" from 5 to 32
  4. Change setting "Min Thread Pool Size" from 2 to 16
  5. Restart Glassfish.
  1. 进入管理控制台
  2. 导航到“配置”->“服务器配置”->“线程池”->“http-thread-pool”。
  3. 将设置“最大线程池大小”从 5 更改为 32
  4. 将设置“最小线程池大小”从 2 更改为 16
  5. 重新启动 Glassfish。

回答by inanutshellus

In my case, this was because my Tomcat was set with an insufficient maxHttpHeaderSizefor a particularly complicated SOLR query.

就我而言,这是因为我的 Tomcat 设置的不足以maxHttpHeaderSize进行特别复杂的 SOLR 查询。

Hope this helps someone out there!

希望这可以帮助那里的人!

回答by Jacob van Lingen

I did also stumble upon this error. In my case the problem was I was using JRE6, with support for TLS1.0. The server only supported TLS1.2, so this error was thrown.

我也偶然发现了这个错误。就我而言,问题是我使用的是 JRE6,并支持TLS1.0。服务器只支持TLS1.2,所以抛出这个错误。

回答by Nirmal Mangal

I know this thread is little old, but would like to add my 2 cents. We had the same "connection reset" error right after our one of the releases.

我知道这个线程有点旧,但想添加我的 2 美分。在我们发布其中一个版本后,我们立即遇到了相同的“连接重置”错误。

The root cause was, our apacheserver was brought down for deployment. All our third party traffic goes thru apacheand we were getting connection reset error because of it being down.

根本原因是,我们的apache服务器被关闭以进行部署。我们所有的第三方流量都通过apache,我们因为它被关闭而收到连接重置错误。