[jira] [Commented] (KUDU-1963) Java client logs NPE if a connection is closed by client during negotiation

["Todd Lipcon (JIRA)" <ji...@apache.org>]

    [ 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)