> > Do you really need to create that dispatcher dynamically? You can create a > custom static one that has dynamic behavior, basically just calling > UserGroup... and PrivilegedAction. I mean, I don't really see why the > dispatcher itself must be created dynamically, only its behavior needs to > access these methods. >
Thanks for the reply. Not sure if I get what you are suggesting. The dispatcher that I want to use depends on the userName which is "dynamic state" that is known when the actor is created. How could I provide this statically in advance? (Or alternatively how could a statically created dispatcher access this "local state" when actors or futures are submitted to run on it?) > > -Endre > > > On Tue, Aug 26, 2014 at 11:23 AM, <[email protected] <javascript:>> > wrote: > >> Hi, >> >> is it possible to start an actor with a dynamically created dispatcher? I >> know that a dispatcher can be configured >> <http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html#Setting_the_dispatcher_for_an_Actor> >> per >> actor, however this dispatcher is created and configured statically. I >> rather look for something like: >> >> def createExecutorService(localContext: ...): ExecutorService = ... >> val localContext = ... >> context.actorOf(someProps.withDispatcher(createExecutorService( >> localContext))) >> >> The use-case is using secure impersonation when interacting with hadoop. >> When interacting with hadoop I dynamically create an actor (that internally >> spawns Futures on its dispatcher). For secure impersonation each code >> section that interacts with hadoop has to be wrapped in something like: >> >> UserGroupInformation.createProxyUser(userName, UserGroupInformation. >> getLoginUser).doAs { >> new PrivilegedAction[A] { >> def run() = { ... } >> } >> } >> >> To avoid spreading this over the actor's code a dynamically created >> dispatcher could help (in this case the userName is the localContext). >> If that is configured with a ThreadFactory like this: >> >> val tf: ThreadFactory = _ >> new ThreadFactory { >> override def newThread(r: Runnable) = { >> tf.newThread(new Runnable { >> override def run() = { >> UserGroupInformation.createProxyUser(userName, >> UserGroupInformation.getLoginUser).doAs(new PrivilegedAction[Unit] { >> override def run() = r.run() >> }) >> } >> }) >> } >> } >> >> all code executed by the actor (and its spawned Futures) would >> automatically be executed on behalf of a given hadoop-user. >> >> Thanks for any help/hints/pointers, >> Volker >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Akka Team > Typesafe - The software stack for applications that scale > Blog: letitcrash.com > Twitter: @akkateam > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
