[
https://issues.apache.org/jira/browse/SOLR-13778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001156#comment-17001156
]
Dawid Weiss commented on SOLR-13778:
------------------------------------
bq. I believe we also see these exceptions when "test solr nodeA" talks to
"test solr nodeB" (although i suspect you are correct that this is also only
after "nodeB" has been stoped/started
This will happen in any kind of situation when a hard-closed socket is reused
from client side. I understand the winsock api description and the example I
attached reproduces this behavior easily. I'm sure you could extract a simpler
setup without jetty at all (just with java socket APIs).
bq. Which seems to raise the question: (How) Can we reliably ensure that
SolrClients get re-instantiated (or have existing connections dropped) if the
"remote" server is restarted?
Technically it's already done -- the only unhandled situation is SSLException
that wraps socket exception with recv failed. This could be detected and
handled like other socket exceptions in solr retry handler.
bq. Could/Should we make SolrHttpRequestRetryHandler close & re-open any
existing connections (prior to retry) if there was a Socket/SSL Exception?
One thing is that a better way would be to fix this in Jetty. Those socket
connections should be dropped gracefully then windows wouldn't throw those odd
exceptions and the SSL layer would handle them better (hopefully). Perhaps
there are other reasons for an SSLException which should *not* cause a retry...
I'm not really sure.
> Windows JDK SSL Test Failure trend: SSLException: Software caused connection
> abort: recv failed
> -----------------------------------------------------------------------------------------------
>
> Key: SOLR-13778
> URL: https://issues.apache.org/jira/browse/SOLR-13778
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: RecvFailedTest.java, dumps-LegacyCloud.zip,
> logs-2019-12-12-1.zip, recv-multiple-2019-12-18.zip
>
>
> Now that Uwe's jenkins build has been correctly reporting it's build results
> for my [automated
> reports|http://fucit.org/solr-jenkins-reports/failure-report.html] to pick
> up, I've noticed a pattern of failures that indicate a definite problem with
> using SSL on Windows (even with java 11.0.4
> )
> The symptommatic stack traces all contain...
> {noformat}
> ...
> [junit4] > Caused by: javax.net.ssl.SSLException: Software caused
> connection abort: recv failed
> [junit4] > at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
> ...
> [junit4] > Caused by: java.net.SocketException: Software caused
> connection abort: recv failed
> [junit4] > at
> java.base/java.net.SocketInputStream.socketRead0(Native Method)
> ...
> {noformat}
> I suspect this may be related to
> [https://bugs.openjdk.java.net/browse/JDK-8209333] but i have no concrete
> evidence to back this up.
> I'll post some details of my analysis in comments...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
