actor

I have recently started looking into the Akka 2.0 framework and was able to get some code running, spawning actors that perform simple oracle database calls, performing simple calculations and whatnot, nothing in production however. What I want to know, is there a general rule of thumb or best practice to determining how many actors to spawn for certain types of tasks? Say for example, I have a connection pool of 200 jdbc connections, Do I create an actor to represent each connection? Do I create a handful of them and use a round-robin approach? Thanks. Note that numberOf(actors) != numberOf

I am running the Akka 2.0.2 microkernel and want to implement an authentication scheme for untrusted remote actors. The first thing that comes to mind is to set up an authentication actor which returns a reference to the work actor when authentication succeeds. However, how should I protect the work actor from simply being directly looked up remotely via actorFor(), circumventing authentication altogether? That is, I want to prevent remote actors from accessing actors in my microkernel actor system without authentication. Not giving the work actor a name in actorOf() is not enough, because it

I would like to leverage reliable actor model in the azure service fabric. Our actor model computation requires specific software installed on the vm node. Can I have custom software installed (on top of the azure service fabric software) in the vm nodes so that I can leverage this software in the actor model computation? As part of the my actor model deployment into azure service fabric, can I author this custom software installation into it? Is this how it should be done? Or are there any other ways? Or is it even possible? Raghu/.. You have multiple options: Install the software manually on

I have a fairly standard mechanism in Java for solving the problem: Work items must be scheduled to execute at a particular time Each work item must then wait on a condition becoming true Work items should be cancellable The solution I use is as follows: Have a single-threaded scheduler to schedule my work items Have an ExecutorService (which may be multi-threaded) Each scheduled work item then submits the actual work to the ExecutorService . The returned Future is cached in a map. A completion service is used to remove the future from the cache when the work is completed Items can be

Is it possible to make an Actor wait for X amount of seconds to receive any message, and if a message is received, process it as usual, otherwise send a message to some other Actor (pre-determined in the constructor)? Viktor Klang Yes, if you want to wait for any message, you simply set a receiveTimeout : http://doc.akka.io/docs/akka/current/scala/actors.html#receive-timeout (The docs is slightly misleading here, you can set the receiveTimeout after every message also) Tomasz Nurkiewicz It's possible, have a look at Akka Actor "ask" and "Await" with TimeoutException . But keep in mind that

From what I've gathered, the "ask" pattern is considered a bad practice and should be avoided. Instead, the recommended pattern is the "actor per request" model. However, this doesn't make sense to me, as the "ask" pattern does exactly this - it creates a lightweight actor per request. So why is this then considered bad, especially when futures are far more composable and are able to more elegantly handle the collation of multiple send/receives? From Akka docs : "There are performance implications of using ask since something needs to keep track of when it times out, there needs to be

The Akka Testing docs give the following way to create a TestActorRef: import akka.testkit.TestActorRef val actorRef = TestActorRef[MyActor] How do I extend this for testing an existing actor that takes constructor arguments? When I try running this as is, substituting in my actor class, I get the following error: "error while creating actor akka.actor.ActorInitializationException:Could not instantiate Actor Make sure Actor is NOT defined inside a class/trait, if so put it outside the class/trait, f.e. in a companion object, OR try to change: 'actorOf(Props[MyActor]' to 'actorOf(Props(new