[
https://issues.apache.org/jira/browse/HADOOP-15602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541840#comment-16541840
]
Daryn Sharp commented on HADOOP-15602:
--------------------------------------
Nice. This is something I've long pondered doing (even just last week) since
clients rapidly reconnecting (ex. overwhelmedthe call queue) may degrade reader
performance by repeatedly authenticating just to be disconnected again.
I'm not sure there's benefit to using a custom callq and scheduler etc since
those are predicated on weighting users. The user isn't known until the auth
completes so everything is prio 0 and a fair call queue is a no-op.
I'll try to look at the more throughly this week. Did you make sure that it
works correctly when requests are split over multiple sasl packets? Or that
clients are correctly disconnected after errors, etc?
> Support SASL Rpc request handling in separate Handlers
> -------------------------------------------------------
>
> Key: HADOOP-15602
> URL: https://issues.apache.org/jira/browse/HADOOP-15602
> Project: Hadoop Common
> Issue Type: Improvement
> Components: ipc
> Reporter: Vinayakumar B
> Assignee: Vinayakumar B
> Priority: Major
> Attachments: HADOOP-15602.01.patch
>
>
> Right now, during RPC Connection establishment, all SASL requests are
> considered as OutOfBand requests and handled within the same Reader thread.
> SASL handling involves authentication with Kerberos and SecretManagers(for
> Token validation). During this time, Reader thread would be blocked, hence
> blocking all the incoming RPC requests on other established connections. Some
> secretManager impls require to communicate to external systems (ex: ZK) for
> verification.
> SASL RPC handling in separate dedicated handlers, would enable Reader threads
> to read RPC requests from established connections without blocking.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
