[ 
https://issues.apache.org/jira/browse/SOLR-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260540#comment-15260540
 ] 

Hoss Man commented on SOLR-9039:
--------------------------------

Some investigation lead me to this java code using jetty to implement a proxy 
where the author mentioned having similar problems and was able to work around 
it with an explict handshake timeout of 0...

https://github.com/adamfisk/LittleProxy/blob/7be308b2a9d8692835c3091d49a9f165f038ce41/src/test/java/org/littleshoot/proxy/TestUtils.java#L116
{code:title=LIttleProxy code snippet, FYI: '0x' is the username of the person 
who left the comment}
if (enableHttps) {
    // Add SSL connector
    org.eclipse.jetty.util.ssl.SslContextFactory sslContextFactory = new 
org.eclipse.jetty.util.ssl.SslContextFactory();

    SelfSignedSslEngineSource contextSource = new SelfSignedSslEngineSource();
    SSLContext sslContext = contextSource.getSslContext();

    sslContextFactory.setSslContext(sslContext);
    SslSocketConnector connector = new SslSocketConnector(
            sslContextFactory);
    connector.setPort(0);
    /*
     * <p>Ox: For some reason, on OS X, a non-zero timeout can causes
     * sporadic issues. <a href="http://stackoverflow.com/questions
     * /16191236/tomcat-startup-fails
     * -due-to-java-net-socketexception-invalid-argument-on-mac-o">This
     * StackOverflow thread</a> has some insights into it, but I don't
     * quite get it.</p>
     * 
     * <p>This can cause problems with Jetty's SSL handshaking, so I
     * have to set the handshake timeout and the maxIdleTime to 0 so
     * that the SSLSocket has an infinite timeout.</p>
     */
    connector.setHandshakeTimeout(0);
    connector.setMaxIdleTime(0);
    httpServer.addConnector(connector);
}
{code}

..unfortunately that method ({{setHandshakeTimeout}}) no longer exists with 
current versions of jetty, and cursory searches of the current jetty API 
/migration docs didn't suggest any obvious replacement.

Reviewing the linked stackoverflow post didn't lead me to any obvious insights, 
other then that if the same underlying problem was the cause of both the SO 
problem and our clientAuth testing probem, then it seemed like it should have 
been fixed already in recent versions of java -- but i may just be 
missunderstanding how java bug fix versions are used.  Some possibly relevant 
OpenJDK bug URLs (again: assuming this is really the same problem)...

* https://bugs.openjdk.java.net/browse/JDK-8021820
* https://bugs.openjdk.java.net/browse/JDK-8022394
* https://bugs.openjdk.java.net/browse/JDK-8022668
* https://bugs.openjdk.java.net/browse/JDK-8035897

> Get to the bottom of why clientAuth (SSL certificate) testing on OSX doesn't 
> work
> ---------------------------------------------------------------------------------
>
>                 Key: SOLR-9039
>                 URL: https://issues.apache.org/jira/browse/SOLR-9039
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>
> When randomized SSL/clientAuth testing was introduced in SOLR-3854 it was 
> quickly determined that something about OSX didn't play nicely with the way 
> we were testing clientAuth certificates...
> https://issues.apache.org/jira/browse/SOLR-3854?focusedCommentId=13897983#comment-13897983
> https://svn.apache.org/r1567643
> At the time no additional investigation into the root problem was attempted.
> As part of SOLR-9028, I spent a little time trying to verify if this was 
> still a problem, and determined it was. I briefly attempted to get to the 
> bottom of it, and compiled a few notes on things to look into -- but 
> ultimately i don't have the time/resources to do any serious test on OSX 
> myself, and i didn't want this to block SOLR-9028 so i'm spinning it out into 
> it's own issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to