[
https://issues.apache.org/jira/browse/HADOOP-15813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636927#comment-16636927
]
Steve Loughran commented on HADOOP-15813:
-----------------------------------------
FWIW, the abfs connector in the hadoop-azure lib switched to a higher
performance SSL library than the JVM's own;
Checkstyle is minor, test failure not.
{code}
[ERROR] TestSaslRPC.testKerberosServer:692->assertAuthEquals:929
[ERROR] TestSaslRPC.testKerberosServer:692->assertAuthEquals:929
[ERROR] TestSaslRPC.testKerberosServer:692->assertAuthEquals:929
[ERROR] TestSaslRPC.testKerberosServer:692->assertAuthEquals:929
[ERROR] TestSaslRPC.testKerberosServer:692->assertAuthEquals:929
[ERROR] TestSaslRPC.testNoClientFallbackToSimple:575->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testNoClientFallbackToSimple:575->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testNoClientFallbackToSimple:575->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testNoClientFallbackToSimple:575->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testNoClientFallbackToSimple:575->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServerWithTokens:622->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServerWithTokens:622->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServerWithTokens:622->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServerWithTokens:622->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServerWithTokens:622->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServer:563->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServer:563->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServer:563->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServer:563->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testSimpleServer:563->assertAuthEquals:923
expected:<[SIMPLE]> but was:<[java.lang.IllegalStateException: Unknown/Unloaded
token identifier for token kind ]>
[ERROR] TestSaslRPC.testTokenOnlyServer:661->assertAuthEquals:929
[ERROR] TestSaslRPC.testTokenOnlyServer:661->assertAuthEquals:929
[ERROR] TestSaslRPC.testTokenOnlyServer:661->assertAuthEquals:929
[ERROR] TestSaslRPC.testTokenOnlyServer:661->assertAuthEquals:929
[ERROR] TestSaslRPC.testTokenOnlyServer:661->assertAuthEquals:929
{code}
I'm going to conclude that making the existing token check code check for
null-nes breaks those few bits of code which actually expect it, and that a
stricter method is going to have to go in, even if it's just some utility
wrapper we can put around 95% of uses of decodeIdentifier in the hadoop code
itself
> Enable more reliable SSL connection reuse
> -----------------------------------------
>
> Key: HADOOP-15813
> URL: https://issues.apache.org/jira/browse/HADOOP-15813
> Project: Hadoop Common
> Issue Type: Bug
> Components: common
> Affects Versions: 2.6.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Priority: Major
> Attachments: HADOOP-15813.patch
>
>
> The java keep-alive cache relies on instance equivalence of the SSL socket
> factory. In many java versions, SSLContext#getSocketFactory always returns a
> new instance which completely breaks the cache. Clients flooding a service
> with lingering per-request connections that can lead to port exhaustion. The
> hadoop SSLFactory should cache the socket factory associated with the context.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
