[
https://issues.apache.org/jira/browse/KUDU-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15950035#comment-15950035
]
Todd Lipcon commented on KUDU-1963:
-----------------------------------
I changed the log message for "unexpected exception" to include the
"closedByClient" flag, and in all cases where we see unexpected exceptions,
'closedByClient=true'. So I think the "renegotiation" thing is a bug in either
Netty or Java's SSL implementation that it misdiagnoses the error. The NPE on
follow-up is obviously our bug, though. I'll work on fixing this.
> Java client logs NPE if a connection is closed by client during negotiation
> ---------------------------------------------------------------------------
>
> Key: KUDU-1963
> URL: https://issues.apache.org/jira/browse/KUDU-1963
> Project: Kudu
> Issue Type: Bug
> Components: client
> Affects Versions: 1.3.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Critical
>
> This is noted in KUDU-1894 but I don't know if it's the root cause of the
> ITClient flakiness, so I'm opening a new JIRA for this:
> If the client is closed (or a connection to a TS is closed) while it's in the
> progress of negotiating, it will result in an error stating
> "javax.net.ssl.SSLException: renegotiation attempted by peer; closing the
> connection" followed by an NPE in sendQueuedRpcs().
> This is being triggered by Impala in a stress workload with a high query rate.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
