actor | 易学教程

Actors Mailbox Overflow. Scala

阅读更多关于 Actors Mailbox Overflow. Scala

问题 Im currently working with two actors in scala. One, the producer , produces some data and sends it to a parcer . The producer sends a HashMap[String,HashMap[Object,List[Int]]] through a message (along with this to mark the sender): parcer ! (this,data) The parser is constantly waiting for messages like so: def act(){ loop{ react{ case (producer, data)=> parse(data); } } } The program runs perfectly in normal circunstances. The problem comes with big volumes of data and many messages sent (The

Actor_更轻量化的并发处理模型

阅读更多关于 Actor_更轻量化的并发处理模型

Actor_更轻量化的并发处理模型 JAVA在JDK5之前写并发程序是非常麻烦的，你要么继承Thread类，要么实现Runnable接口，同步机制的力粒度也很粗。JDK5之后，引入了Concurrent包，增加了很多并发特性的支持，如Callable<T>接口，可以使用Future<T>来获取每个任务返回的结果，而原来的Runnable是没有这个能力的。还有就是更细粒度的锁，如Lock接口。 Actor Model最早是在上世纪70-80年代就被提出来了，是用来编写并行计算或分布式系统的高层次抽象，让程序员不必为多线程模式下共享锁而烦恼， Erlang 最先实现Actor Model，SCALA参考了这个实现。 Actors将状态和行为封装在一个轻量的进程/线程中，但是不和其他Actors分享状态，每个Actors有自己的封闭环境，当需要和其他Actors交互时，通过发送事件和消息，发送是异步的，非堵塞的(fire-and-forget)，发送消息后不必等另外Actors回复，也不必暂停，每个Actors有自己的消息队列，进来的消息按先来后到排列，这就有很好的并发策略和可伸缩性，可以建立性能很好的事件驱动系统。 SCALA实现Actor Model有两种实现方式：基于线程的实现：类似JAVA中的thread方式，通过定义一个thread-specific方法

Creating a TestActorRef results in NullPointerException

阅读更多关于 Creating a TestActorRef results in NullPointerException

I am trying to get a TestActorRef like that class NotifySenderTest(_system: ActorSystem) extends TestKit(_system) with ImplicitSender with WordSpecLike with Matchers with BeforeAndAfterAll with BeforeAndAfter { def this() = this(ActorSystem("NotifySenderTest")) override def afterAll { TestKit.shutdownActorSystem(system) } "A NotifySender" must { "be able to process the required messages" in { val actorRef = TestActorRef[NotifySender] //Line 92 } } the this actor class NotifySender extends Actor with Stash { import Tcp._ import context.system def receive = { [...] } } But this leaves me with

Get or create child Akka actor and ensure liveness

阅读更多关于 Get or create child Akka actor and ensure liveness

问题 I am trying to use a hierarchy of Akka actors to handle per user state. There is a parent actor that owns all the children, and handles the get-or-create in the correct way (see a1, a2): class UserActorRegistry extends Actor { override def Receive = { case msg@ DoPerUserWork(userId, _) => val perUserActor = getOrCreateUserActor(userId) // perUserActor is live now, but will it receive "msg"? perUserActor.forward(msg) } def getOrCreateUserActor(userId: UserId): ActorRef = { val childName =

Replacing bad performing workers in pool

阅读更多关于 Replacing bad performing workers in pool

I have a set of actors that are somewhat stateless and perform similar tasks. Each of these workers is unreliable and potentially low performing. In my design- I can easily spawn more actors to replace lazy ones. The performance of an actor is assessed by itself. Is there a way to make the supervisor/actor pool do this assessment, to help decide which workers are slow enough for me to replace? Or is my current strategy "the" right strategy? I'm new to akka myself, so only trying to help, but my attack would be something along the following lines: Write your own routing logic, something along

React for futures

阅读更多关于 React for futures

问题 I am trying to use a divide-and-conquer (aka fork/join) approach for a number crunching problem. Here is the code: import scala.actors.Futures.future private def compute( input: Input ):Result = { if( pairs.size < SIZE_LIMIT ) { computeSequential() } else { val (input1,input2) = input.split val f1 = future( compute(input1) ) val f2 = future( compute(input2) ) val result1 = f1() val result2 = f2() merge(result1,result2) } } It runs (with a nice speed-up) but the the future apply method seems

How to Cancel an Akka actor?

阅读更多关于 How to Cancel an Akka actor?

I have an akka actor(worker) that receives a request and replies to it. The request processing can take 3-60 minutes. Caller(also an actor) is currently using !!! and waiting on future.get, however the design of Caller actor can be changed if required. Also, I'm currently using EventDriven dispatcher. How do i Cancel(user initiated) the request processing so that the worker actor is freed up and returns to the ready state to receive new requests? I was hoping for a method similar to java.util.concurrent.Future's cancel method but couldn't find in Akka 1.1.3 Edit: We tried to get the behavior

How to discover that a Scala remote actor is died?

阅读更多关于 How to discover that a Scala remote actor is died?

问题 In Scala, an actor can be notified when another (remote) actor terminates by setting the trapExit flag and invoking the link() method with the second actor as parameter. In this case when the remote actor ends its job by calling exit() the first one is notified by receiving an Exit message. But what happens when the remote actor terminates in a less graceful way (e.g. the VM where it is running crashes)? In other words, how the local actor can discover that the remote one is no longer

Akka and its Error Kernel

阅读更多关于 Akka and its Error Kernel

I am reading the Akka ( Java lib ) docs and need clarification on some of their own proclaimed Akka/Actor Best Practices . Actors should not block (i.e. passively wait while occupying a Thread) on some external entity...The blocking operations should be done in some special-cased thread which sends messages to the actors which shall act on them. So what does a code example of this look like in Akka/Java? If an Actor isn't an appriote place to put code that has to block, then what does satisfy the definition of "some special-cased thread"? Do not pass mutable objects between actors. In order to

Scala: Why are Actors lightweight?

阅读更多关于 Scala: Why are Actors lightweight?

问题 What makes actors so lightweight? I'm not even sure how they work. Aren't they separate threads? 回答1: When they say lightweight they mean that each actor is not mapped to a single thread. JVM offers shared memory threads with locks as the primary form of concurrency abstractions. But shared memory threads are quite heavyweight and incur severe performance penalties from context switching overheads. For an actor implementation based on a one-to-one mapping with JVM threads, the process payload