You can use multiple active inference agents to achieve load balancing, scaling, and performance. These are known as multi-engine features. You must be aware of some design considerations when designing project that take advantage of these multi-engine features.
For instance, an Agent X receives an event E, fires a rule R1 that creates a concept C1. An agent Z receives an event E2, fires a rule R2 that joins concept C1 and event E2.
See the StateMachineMultiEngineExample example to see a demonstration of this point. (Requires TIBCO BusinessEvents Enterprise Suite).
Scorecards are not shared between agents. (This is true in all OM types.) Each inference agent maintains its own set of scorecards and the values in each agent can differ. This enables scorecards to be used for local purposes and minimizes contention between the agents.
As an analogy consider a bank ATM scenario. Money can be drawn from the same account using different ATMs. However, each ATM maintains a "scorecard" indicating only how much money it dispenses.
An agent key property (Agent.AgentGroupName.key) is available for tracking scorecards. See
Defining a Unique Key for Each Agent.
In a load balanced and (optionally) fault tolerant group of agent instances, event instances are
clustered between agents in an agent group—they are not shared. That is, each event instance is present on only one agent in the cluster.
Cache cluster services provide for reassignment of ownership of these events to other agents in the same group, in the event of node failure. The events owned by this agent are redistributed to the remaining agents. (Therefore there is no single point of failure.)
See the Events-MultiEngineExample example for a demonstration of this point.
State machines can be configured to have state timeouts. The objects are shared across all agents, and the agents in the cluster collaborate to take ownership of management of the state machines, thereby providing automatic fault tolerance.
Multiple agents can read and write to the same cache cluster and at times operate on the same set of objects. You must therefore deal with the possibility of concurrent modifications. Use locks to deal avoid race conditions.
See Locking and Synchronization Functions in Preprocessors for details on managing access to objects in preprocessors, which are multi-threaded.
Multiple agents can work on different properties of the same concept without issues. The object itself does not need to be explicitly locked. Agents update the cluster based on the actual properties being modified.
Both agents on startup are activated based on the maxActive setting and therefore they both listen to the destinations on which events (E1 and E2) arrive.
The events are clustered but are not shared. For example Agent A1 receives the event E1. If the Time to Live of the event is > 0, then the event is acknowledged in the channel and moved to the cluster.