[
https://issues.apache.org/jira/browse/KUDU-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon updated KUDU-1897:
------------------------------
Attachment: rcache.png
The problem was substantially resolved when I disabled the krb5 replay cache on
the master using the KRB5RCACHETYPE=none environment variable. We should think
about whether the replay cache is providing any security value for us in our
particular negotiation protocol (eg does TLS already avoid replays for us?).
> GSSAPI negotiation single-threaded and very slow under concurrency
> ------------------------------------------------------------------
>
> Key: KUDU-1897
> URL: https://issues.apache.org/jira/browse/KUDU-1897
> Project: Kudu
> Issue Type: Bug
> Components: rpc, security
> Affects Versions: 1.3.0
> Reporter: Todd Lipcon
> Priority: Critical
> Attachments: rcache.png
>
>
> I'm running an Impala workload with ~10 concurrent clients submitting queries
> that take a few seconds each on a 9 node cluster. The master is pegging on
> core in negotiation, and has a bunch of other negotiation threads blocked on
> a mutex within SASL.
> Each negotiation is taking 2-3 seconds due to waiting on this lock.
> This severely restricts connection throughput, and probably needs to be
> addressed for 1.3.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
