Multi-Agent Features and Constraints
Concurrency affects the way events and objects are processed in a multi-agent configuration, or with concurrent RTC.
Multi-agent features can be used in two ways:
- Deployment of instances of the same agent, each in a different processing unit, for load balancing and fault tolerance. (A processing unit is one JVM, also known as a node.)
- Deployment of instances of different agents, to achieve rule-chaining for high distribution of the work load and high performance.
In both multi-agent cases, the agents are in the same cache cluster and work on the same ontology objects and, to provide performant systems.
Concepts are Shared Across Agents Asynchronously
All concepts are shared between agents in the cluster in an asynchronous manner. 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.
Therefore, there is inherent latency between an object change in an agent, and reception of the notification by the other agents in the cluster.
It is recommended that you explicitly consume events when their work is done so that they do not cause any unwanted (unforeseen) actions to occur by their presence in the Rete network.
Scorecards are Local to the Agent
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.AgentClassName.key) is available for tracking scorecards. It identifies an agent uniquely so that its scorecard can be restored from the cache.
Events are Owned by the Agent that Receives Them
In a load balanced group of agents, events (messages) received by an agent are owned by that agent. Even when the event is retrieved from cache (for example for a join condition), the ownership is maintained. No other agent can work with that event, unless the owning agent fails.
In the event of engine failure, cache cluster services provide for reassignment of ownership of clustered events to other agents in the same agent group, so there is no single point of failure. (Of course, if the event’s time-to-live period expires during this transition, the event expires and is not reassigned.)
Events from Queues
Events received from a queue are each taken up by one agent or another. For example, when an agent X receives an Event E1 from a queue, agent B in the same agent group does not see the event. To set up load balancing of events arriving from a queue, you enable the same destination in the agents you want to use. Agents used for load balancing are generally agents in the same group (class) but do not have to be.
Events from Topics
Unlike messages received from a queue, messages sent on a topic are received by all agents that actively listen to the topic. Each agent generates its own event instance (with its own ID) when receiving the message. While it could be useful for multiple agents to receive events sent on a topic, this often leads to undesirable results. Care must be taken to ensure that just one agent receives topic-based messages.