问题标签 [actor]

如果 A 是扩展用例（不是基本用例），A 可以直接被参与者引用吗？

任何人都知道单元测试 Scala 演员的好方法吗？在一般意义上，我有一个接收消息并会发送其他消息作为响应的参与者。这是在多个线程上完成的，不正确的参与者可能会发送错误消息或根本不发送消息。我需要一种简单的方法来创建一个模型 Actor，它可以向被测试的 Actor 发送和接收消息。有这方面的经验吗？

是否有任何指南或教程可以解释远程使用 scala 演员的可能性？到目前为止，我发现的只是一个例子（没有评论），但这还不够。

最近我一直在研究支持演员/代理/无共享架构的替代语言 - 即。scala、clojure 等（clojure 也支持共享状态）。

到目前为止，我阅读的大多数文档都集中在介绍级别。我正在寻找的是四个更高级的文档，但没有共享任何基础。

为什么 ？它有助于理解设计思维的变化。简单的示例很简单，但在现实世界的 Java 应用程序（单线程）中，您可以拥有具有 1000 个具有复杂关系的成员的对象图。但是随着基于代理的并发开发，它引入了一套全新的想法，以便在设计大型系统时理解。IE。代理粒度 - 一个代理应该管理多少状态 - 对性能等的影响，或者是将共享状态对象图映射到基于代理的系统的良好模式。将域模型映射到设计的技巧。讨论不是关于技术，而是更多关于如何在设计中最好地使用技术（现实世界的“复杂”示例会很棒）。

我在 Java 中从事金融应用程序的工作，并且获得正确的并发性是很痛苦的。Erlang 和演员模型应该非常适合大规模并发应用程序，但我不知道如何在 Java 中做到这一点。我知道有 Jetlang、FunctionalJava、kilim 等库，但它们通常不会超出简单的示例。

假设我需要处理三个或四个不同的事件，例如从市场数据馈送、订单/交易馈送中计算一些数字以及“输出”这些数据的一些衍生产品。大多数情况下，这些事件或数据流需要按顺序处理（至少相对于某些键的顺序...例如，特定交易品种的所有订单都必须按顺序处理，但与尊重不相关的符号）

我用改变状态的方法创建了一个普通的 Java 对象。我没有让这些方法直接改变状态，而是将它们的参数（通过将它们转换为命令对象）放入一个 fifo 队列（erlang 的邮箱），以及一个处理该队列的 react() 方法。这样，所有更新都必须经过一个队列，并且 react() 方法一次只能访问一个更新。从理论上讲，这应该让我无需在此方法上锁定或同步。

然而，这个队列基本上是一个生产者/消费者队列，这意味着它是一个阻塞队列。阻塞对可扩展性非常不利。此外，拥有一个队列意味着我的所有更新命令对象（不同类型的）都以一些过于通用的超类型（如 Object）从队列中出来，我必须将它们转换回正确的类型并让 react() 处理它们.

一旦这个演员化的对象产生一个输出，被另一个这样的对象消费，我就会经历同样的过程。换句话说，我已经将编程模型从面向对象（使用返回结果的方法）更改为某种持续传递噩梦，在这种噩梦中我的所有方法都变为异步。

有什么想法可以解决这个问题吗？

在ScalaActors.pdf上的这张幻灯片中，当消息发送到 pong actor 时，单引号表示什么？

我有以下代码：

据我了解，外部参与者不会阻塞，f.get因为这实际上是由一个单独的参与者（在SomeEvent处理程序内部创建的参与者）执行的。

它是否正确？

我在 Java 中有一个相当标准的机制来解决这个问题：

• 必须安排工作项在特定时间执行
• 然后每个工作项必须等待条件变为真
• 工作项目应该是可取消的

我使用的解决方案如下：

1. 有一个单线程调度程序来安排我的工作项目
2. 有一个ExecutorService（可能是多线程的）
3. 然后每个计划的工作项将实际工作提交给ExecutorService. 返回Future的缓存在地图中。完成服务用于在工作完成时从缓存中删除未来
4. 可以通过缓存的期货取消项目

当然，我的 executor 至少需要与我期望的阻塞工作项的数量一样大，但这在实践中不是问题。

所以现在我正在使用 Scala 进行编码并使用 actor 框架。假设我的工作项可以封装在发送给参与者的事件中：

1. 我将使用什么机制来安排特定时间的工作项？
2. 如果工作项是发送给参与者的事件，我如何确保后备线程池大于可以同时阻塞的项目数
3. 如何取消之前安排的工作项目？

Erlang 中 Actor 模型的特点之一是透明分布。除非我误解了，否则当你在参与者之间发送消息时，理论上你不应该假设它们在同一个进程空间中，甚至位于同一台物理机器上。

我一直认为分布式容错系统需要仔细的应用程序设计来解决围绕排序/因果关系和共识（以及其他）的固有问题。

我很确定 Erlang 不会承诺透明地解决这些问题，所以我的问题是，Erlang 开发人员如何应对这个问题？您是否将您的应用程序设计为好像所有参与者都在同一个进程空间中，然后只在实际分发它们时才解决分发问题？

如果是这样，Erlang 的这种透明分布特性是否真的只涉及用于远程消息传递的有线协议，而不是真正的透明，因为真正的分布式应用程序仍然需要在应用程序层进行仔细设计？

我正在阅读有关 Actor 模型的演示文稿，每个人都声称它优于共享状态并行编程，因为它避免了许多陷阱，如死锁和竞争条件。我在问自己这种说法的具体内容是什么。如果它避免了这些问题，它是如何做到的？