[
https://issues.apache.org/jira/browse/HADOOP-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940561#comment-13940561
]
Daryn Sharp commented on HADOOP-10280:
--------------------------------------
bq. Haven't quite figured how to do that cleanly yet
That's because you can't at this layer w/o terribly violating abstractions.
This rpc layer is responsible for accepting connections, reading rpc messages,
creating an opaque call object, and queueing it for the handlers. The handlers
use a rpc invoker & engine to decode the call and invoke a method in the app's
rpc server impl. Nothing is known about the opaque call while it's in or taken
out of the callq. If you want to schedule based on something other than source
address, remote user, or rpc header fields, then the scheduling needs to be
part of the app's rpc server impl.
I've wanted to do a type of scheduling of method invocation in the NN and
concluded that I should reduce the number of handlers (possibly to 1), the rpc
server impl does custom scheduling/queuing, and the impl maintains it's own set
of handlers for consuming from its custom queue.
All said, I'm comfortable with adding {{call.getRemoteUser()}} which returns
the connection's remote user.
> Make Schedulables return a configurable identity of user or group
> -----------------------------------------------------------------
>
> Key: HADOOP-10280
> URL: https://issues.apache.org/jira/browse/HADOOP-10280
> Project: Hadoop Common
> Issue Type: Sub-task
> Reporter: Chris Li
> Assignee: Chris Li
> Attachments: HADOOP-10280.patch, HADOOP-10280.patch,
> HADOOP-10280.patch
>
>
> In order to intelligently schedule incoming calls, we need to know what
> identity it falls under.
> We do this by defining the Schedulable interface, which has one method,
> getIdentity(IdentityType idType)
> The scheduler can then query a Schedulable object for its identity, depending
> on what idType is.
> For example:
> Call 1: Made by user=Alice, group=admins
> Call 2: Made by user=Bob, group=admins
> Call 3: Made by user=Carlos, group=users
> Call 4: Made by user=Alice, group=admins
> Depending on what the identity is, we would treat these requests differently.
> If we query on Username, we can bucket these 4 requests into 3 sets for
> Alice, Bob, and Carlos. If we query on Groupname, we can bucket these 4
> requests into 2 sets for admins and users.
> In this initial version, idType can be username or primary group. In future
> versions, it could be jobID, request class (read or write), or some explicit
> QoS field. These are user-defined, and will be reloaded on callqueue refresh.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
