Events 如何让多个上下文处理Apama中的事件

我试图定义一个监视器，在其中我接收事件，然后在多个上下文中处理它们（如果我理解正确，大致相当于线程），我知道我可以编写

spawn myAction() to myNewContext; 

这将在新的上下文中运行该操作

但是，我希望有一个动作，当事件进入我的监视器时，该动作将响应事件：

on all trigger() as t {
  doMyThing()
}

on all otherTrigger() as ot {
  doMyOtherThing()
}

我是否可以使用特定上下文在所有上定义我的

？差不多

on all trigger() as t in myContext {
  doMyThing()
}

on all otherTrigger() as t in myOtherContext {
  doMyOtherThing()
}

如果不是，在Apama EPL中定义这一点的最佳方式是什么？我还可以让多个上下文在事件到达时处理相同的事件，循环式吗？
来自外部接收者（即外部世界）的Apama事件仅传递给
公共上下文，包括“主”上下文。因此，根据您的体系结构，您可以将您的操作生成到公共上下文中

// set the receivesInput parameter to true to make this context public
spawn myAction() to context("myContext", true);

...

action myAction() {
    on all trigger() as t {
        doMyThing();
    }
}

或者，将您的操作生成到私有上下文，并在公共上下文（通常是主上下文）（将始终存在）中设置事件转发器

生成一个私有上下文并利用频道系统通常是更好的设计，因为它只将事件发送到关心它们的上下文
以扩展一点Madden的答案（我还没有足够的代表发表评论），私有上下文和转发器也是实现真正循环的唯一方法：否则所有上下文将接收所有事件。最简单的方法是使用分区策略（例如，以0结尾的ID转到context-0，或者您监控的每台机器都有一个上下文，等等），因为这样每个关注点都在同一上下文中跟踪，您不必共享状态

我还可以有多个上下文来处理相同的事件，当它们到达时，循环方式

这对我来说并不完全清楚。你在这里的目标是什么？如果您希望通过让“下一个可用”上下文拾取事件来减少延迟，那么这可能不是实现这一点的正确方法-决定哪个上下文处理事件意味着您需要上下文间的通信和协调，这将增加延迟。如果您希望多个上下文处理相同的事件（例如，一个上下文运行您的温度峰值规则，另一个上下文运行您的长期温度平均规则，但两者都将温度读数作为输入），这是一个很好的方法，但这不是我所说的循环制。
Hi@HenryLockwood-谢谢你的回答：）你对我想做的事情是正确的，我想我是以错误的方式看待环境的。我可以理解你关于避免上下文之间的同步（我认为是线程）以最小化延迟的观点。我认为我在Apama的经验不足影响了我如何设计显示器，我需要以不同的方式看待这个问题。@Caribou-我刚到Apama时经常做的一件事是很早就想到如何使事情快速进行。现在我又老又懒了（！）我只是写了一些不愚蠢的代码，然后我会对它进行性能测试，如果需要的话还会进行调优。对于大多数应用程序来说，Apama的速度通常足够快，特别是当您的延迟要求以几十毫秒或更长的时间来衡量时。如果您正在与其他组件进行接口，这些组件通常会比较慢。在大多数情况下，您可以将上下文视为线程——这是一种很好的近似工作方式。
spawn myAction() to context("myNewContext");
on all trigger() as t {
    send t to "myChannel"; // forward all trigger events to the "myChannel" channel
}

...

action myAction() {
    monitor.subscribe("myChannel"); // receive all events delivered to the "myChannel" channel
    on all trigger() as t {
        doMyThing();
    }
}