actor

前言 Actor模型 为并行而生。由于现在单台机器中独立的计算单元也越来越多，Actor模型的重要性也越来越大。Actor模型的理念非常简单：天下万物皆为Actor，Actor之间通过发送消息进行通信。不同的Actor可以同时处理各自的消息，从而获得了大规模的并发能力。 Erlang基于Actor模型实现，我们甚至可以这样认为，没有Erlang在业界竖立的丰碑，Actor模型便不会如此受人关注。目前，几乎所有的主流开发平台上都有了Actor模型的实现，如Java平台下的 Jetlang 以及.NET平台下的 MS CCR 和 Retlang ；还有一些Actor框架专为特定语言设计，如 F#的MailboxProcessor 以及 Scala的Actor类库 ；甚至微软还基于MS CCR构建了一门新的语言 Axum 。 不过对于.NET平台下的开发人员来说，我们最常用的语言是C#。无论您是在使用MS CCR还是Retlang（亦或是我写的 ActorLite ），在消息的执行阶段总是略显尴尬。本文的目的便是提出一种适合C# Actor的消息执行方式，而这种执行方式还会成为我以后公开的C#中“模式匹配”的基础。 Erlang中的执行方式 本文将分为三个部分，您目前正在阅读的第一部分，将会观察Erlang是如何执行消息的。有对比才会有差距

在前两篇文章中，我们了解到 Erlang中灵活的模式匹配 ，以及在 C#甚至F#中会都遭遇的尴尬局面 。那么现在就应该来设计一个解决方案了，我们如何才能在C#这样的语言里顺畅地使用Actor模型呢？不仅如此，最好我们还能获得其它一些优势。 “消息”、“协议”和“接口” Actor模型中的对象如果要进行交互，唯一的手段便是发送消息。不同语言/平台上的消息有不同的表现形式，但是它们所传递的信息是一致的： 做什么事情 做这件事情需要的数据 例如，Erlang中往往会使用Tag Message的格式作为消息： {doSomething, Arg1, Arg2, Arg3, ...} 其中，原子doSomthing表示“做什么”，而后面的ArgN便是一个个的参数，使用Erlang中的模式匹配可以很方便地捕获消息中的数据。在C#等语言中，由于并非专为了Actor模型设计，因此一个Message往往只能是一个对象。但是这个对象的职责并没有减轻，因此我们需要自己处理的事情就多了。我们可能会这样做： 学Erlang的Tag Message，但是这样会产生大量丑陋的类型转换操作，并且丧失了静态检查功能。 为每种消息创建不同的Message类型，但是这样会产生大量类类型，每个类型又有各种属性，非常麻烦。 这两种做法在上一篇文章里都有过讨论，感兴趣的朋友可以再去“回味”一番。那么，究竟什么是消息呢

　　 　　今天粗粗看了老赵的文章 适合C# Actor的消息执行方式 -中看不（3）：中用的解决方案 ，我在想如果用我以前写的消息总线来实现那不是中看也中用了，于是顺手写了一个测试代码（具体内容参见 适合C# Actor的消息执行方式 -中看不（3）：中用的解决方案 回复），说来很惭愧我的消息总线系列已经一年多没有更新了，我这人太懒散惯了，没办法。废话不多说了，下面我就具体讲解一下设计思路。 　　在Actor模式中，最重要的就是Actor间的消息发送以及消息路由了。 　　消息发送：举一个例子实现一个ActorA向ActorB发消息，最简单的方法就是：ActorA中需要内聚或依赖一个ActorB对象，然后就可以直接发消息通讯了，这种方法优点不言而喻- 简单 ，但是当一个系统中存在无数个Actor，一个Actor有可能向N多的其它Actor发消息，这种方法的弊端就暴露无疑了： 强依赖，强耦合。 怎么结局这种问题呢，这时候设计模式中的 中介者模式就可以派上用场了。所有的Actor都向中介者发消息即可，由中介者把消息通过一定的策略路由到特定的Actor，由这个特定的Actor进行处理即可。 　　 消息路由 ：消息路由的关键就是路由表，路由表可以用字典来实现，Key-可以用消息类型+Topic来标记即可，Value ：就用委托函数即可。 具体简略设计图如下： 类图详解： 　　　

I have the following: val future = myActor ? Message And in my actor my receive message has something like this: sender ! Response If I do the following and ignore the response, is there any negative impact? myActor ! Message Maybe I'm just missing where it says this in the documentation. Is it like a method that returns a value and the caller doesn't assign the return value to anything? If I make that call from another actor is there going to be some weird threading issue or memory leaks that result from it? My unit tests don't seem to be affected but it's kind of a contrived. I'm hoping I'm

I've an unexpected behavior when using remote actors. I've a server and a 'client'. The client sends a message to the server actor and the server replies. When I use the '?' operator everything works as expected. I get the answer back from the server. The server: class HelloWorldActor extends Actor { def receive = { case msg => self reply (msg + " World") } } object Server extends App{ Actor.remote.start("localhost",2552); Actor.remote.register("hello-service",Actor.actorOf[HelloWorldActor]) } The client: object Client extends App { // client code val actor = remote.actorFor( "hello-service",

I try to implement a TypedActor in Java following the examples on Typed Actors (Java) . But I'm struggling. I have added akka-actor-1.1-M1.jar , akka-typed-actor-1.1-M1.jar , scala-library.jar but it wasn't enough. I got errors in Eclipse so I also added aspectwerkz-2.0.jar and aspectwerkz-core-2.0.jar to my Build Path. I try to use a TypedActor with custom constructor. But now I get an error at compilation: Exception in thread "main" java.lang.NoSuchMethodError: org.codehaus.aspectwerkz.proxy.Proxy.newInstance([Ljava/lang/Class;[Ljava/lang/Object;ZZ)Ljava/lang/Object; at akka.actor.TypedActor

When using Akka 1.3, do I need to worry about what happens when the actors producing messages are producing them faster than than the actors consuming them can process? Without any mechanism, in a long running process, the queue sizes would grow to consume all available memory. The doc says the default dispatcher is the ExecutorBasedEventDrivenDispatcher. This dispatcher has five queue configuration: Bounded LinkedBlockingQueue Unbounded LinkedBlockingQueue Bounded ArrayBlockingQueue Unbounded ArrayBlockingQueue SynchronousQueue and four overload policies: CallerRuns Abort Discard DicardOldest

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center . Closed 7 years ago . Can I extend actor in use case? for example I have "normal user" , "student user" and "teacher user"... every use case the "normal user" uses it ,by default the "student user" and "teacher user" use it too.. so can I extend "normal user" for "student user" and "teacher user" ? is that popular ? Thanks a lot :)