私のjava.net.SocketExceptionの原因は次のとおりです。接続がリセットされましたか?[重複]
-
06-09-2019 - |
質問
この質問にはすでに答えがあります:
頻繁ではありますが、断続的に発生しています java.net.SocketException: Connection reset
ログにエラーが記録されています。どこにあるのかは不明です。 Connection reset
実際にエラーが発生している原因と、デバッグの方法について説明します。
この問題は、送信しようとしているメッセージとは無関係のようです。メッセージは次のとおりであることに注意してください。 ない connection reset by peer
.
この例外の一般的な原因と、今後の進め方について何か提案はありますか?
代表的なスタック トレースを次に示します (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)
私たちのコンポーネントは、Tomcat で実行される Web アプリケーションであり、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 );
解決
のSocketExceptionのjavadocは、それがあると述べている。
このようなTCPエラー
のように、基礎となるプロトコルに誤りがあることを示すためにスロー
あなたのケースでは、接続は、接続のサーバ側で閉じられているようです。これは、あなたが送信している要求またはその最後の問題の問題である可能性があります。
あなたは、実際のネットワークパケットを表示するために、このような Wiresharkののようなツールを使用して見て可能性がデバッグを支援するために。また、Webサービスをテストするために使用できるJavaコードに代わるクライアントはありますか?これが成功した場合は、Javaコードのバグを示している可能性があります。
あなたはコモンズHTTPクライアントを使用しているなどの一般的なHTTPクライアントのログ記録をrel="noreferrer"> href="http://hc.apache.org/httpclient-3.x/logging.html" のガイド。これはどのようにHTTPレベルで要求をログに記録する方法を教えてくれます。
他のヒント
このエラーの他の側はあなたの側に起こるとしません。相手側が接続をリセットする場合は、例外メッセージは、言う必要があります:
java.net.SocketException reset by peer
原因はHttpClient
内部の接続が古くなっています。 SSLがこのエラーを修正しないため、古い接続を確認してください。解決策:クライアントをダンプし、再作成
Glassfish3 サーバーにデプロイされた Web サービスにアクセスしようとしてこの問題が発生した場合は、http-thread-pool 設定を調整することをお勧めします。これにより、多くの同時スレッドが Web サービスを呼び出したときに発生する SocketExceptions が修正されました。
- 管理コンソールに移動します
- 「構成」->「サーバー構成」->「スレッドプール」->「http-thread-pool」に移動します。
- 「最大スレッド プール サイズ」の設定を 5 から 32 に変更します。
- 「最小スレッド プール サイズ」設定を 2 から 16 に変更します。
- Glassfish を再起動します。
私も、このエラー時につまずくでした。私の場合は問題は、私は<のhref = "https://stackoverflow.com/questions/10500511/how-to-find-what-ssl-tls-version-is-used-inをサポートする、JRE6を使用していたました-java "> TLS1.0 の。サーバはTLS1.2をサポートするので、このエラーがスローされました。
maxHttpHeaderSize
で設定されたため、私の場合、これはでした。
これはそこに誰かに役立ちます願っています!
私は、このエラーのすべての時間を取得し、それが正常なことを検討してください。
一方がもう一方の側が既にハングアップしたときに読みしようとしたときにそれが起こります。こうしてのプロトコルに応じて、これは、またはの問題を指定してもしなくてもよいです。 私のクライアントコードは、特にハングアップしようとしているサーバーに示している場合は、クライアントとサーバの両方が同時にハングアップすることができ、このメッセージは起こりません。
私は自分のコードを実装する方法はたださよならも言わずにハングアップするためのクライアントのためです。 その後、サーバーはエラーをキャッチし、それを無視することができます。 HTTPの文脈では、私は他にはないながら、プロトコルの1つのレベルは、接続ごとに複数次いでつの要求を可能にすると考えています。
このように、あなたは1辺が他にハングアップ続ける可能性がどのように潜在的に見ることができます。私はあなたがされるエラーは、任意の海賊懸念される疑い、あなたは単にあなたのログファイルをいっぱいにそれを維持するためにそれをキャッチできます。
このエラーは、サーバー側で発生します。彼らは手動で作成することができますので、Webアプリケーションのシナリオでは、これらの全ては、危険なわけではありません。 REPONSEが取得される前にブラウザを終了することにより、例えば
例外は、ソケットが他の側から予期せず閉じられたことを意味します。最も可能性の高いWebサービスのバグをトリガーするリクエストを送信している - あなたは、Webサービスを呼び出しているので、これは起こるべきではありません。
これらのケースで全体の要求を記録してみて、あなたは何も異常に気づくかどうかを確認します。それ以外の場合は、Webサービスプロバイダと接触して取得し、それらをあなたのログイン問題とリクエストを送信します。
私はこのスレッドは少し古いですけど、私の2セントを追加したいと思います。 我々は右のリリースの私たちの後に同じ「接続リセット」エラーが発生しました。
根本的な原因は、私たちのapache
サーバを展開するために倒されたました。私たちのすべてのサードパーティのトラフィックはapache
を通して行くと、私たちはので、それがダウンしているの接続リセットのエラーを取得しました。
これは古いスレッドですが、私は昨日java.net.SocketException: Connection reset
に走りました。
サーバー側のアプリケーションは、そのスロットリング設定は一度に1接続を許可するように変更しました!このように、時々呼び出しが通過したと時々ません。私はスロットリングの設定を変更することで問題を解決します。
私もまさにそのエラーを取得しました:Connection reset by peer
。例外はpostForObject()
メソッドを実行している時にSpringのRESTテンプレートによって提起されていました。私にとっての問題は、あまりにも長い間のHTTP URLリクエストでした。サーバーは本当に、その長さの要求を処理するだけで、サーバの設定に移動し、URLリクエストのデフォルトの許容長を上げることができるはずのであればまず、生産URLは、それがどうあるべきかであるかどうかを確認します。
それは私のために問題を解決しますが、注意してください:彼らはURLリクエストの最大長さを固定しているように、アプリケーションは、いくつかのインターネットブラウザ、特に古いもの、上で実行されない場合があります。
。それが役に立てば幸い...
私は読んしようとしていたテキストファイルは、私たちのファイアウォール上のアンチウイルスシグネチャに一致した文字列が含まれていたとき、私はこのエラーを得ています。
FWIW、私はこのエラーを取得しました。おそらくそれが問題を扱うだけで、その特定のサーバーの方法だった。
私が接続しようとしたポートが閉じられたので、私はこのエラーを取得しました。