Concurrency and Project Design : Multi-Agent Features and Constraints

Multi-Agent Features and Constraints
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.
Because of the asynchronous sharing of objects between agents, ensure that events have a long enough time to live setting so that they do not expire before all actions pertaining to the event are done.
It is recommended that you explicitly consume events when their work is done so that they don’t 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 don’t 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.
Event Related Constraints
Repeating Time Events Not Supported
Time events configured to repeat at intervals are not supported in multi-agent configurations. Rule-based time events, however, are supported.
State Machine Timeouts
State machines can be configured to have state timeouts. The agents in the cluster collaborate to take ownership of management of the state machines, thereby providing automatic fault tolerance. (Requires TIBCO BusinessEvents Data Modeling add-on software.)
Multi-Agent Example Showing Event Handling
The following example shows how concepts are shared and events are not shared in a load balancing agent group.
Example Scenario
Agent A has the following rules:
Agent A listens to destinations on which events E1 and E2 arrive.
You start two instances of agent A called A1 and A2. Both are active, therefore they both listen to the destinations on which events E1 and E2 arrive.
At runtime, the arrival of two events illustrates the expected behavior:
1. Agent A1 receives an instance of Event E1:
1.
2.
3.
4.
With Cache Plus Memory mode, Agent A2 receives a notification and loads the instance of concept C1 in its Rete network. With Cache Only mode, Agent A2 has to explicitly load the concept when it will be needed for an RTC.
Note that the event E1 is in the cache, but Agent A2 does not load the event in its Rete network. However, if the node (JVM) containing Agent A1 fails, then Agent A2 moves the pending events to its Rete network.
2. Agent A2 receives an instance of Event E2:
1.
Rule R2 executes because agent A2 is aware of the instance of C1. (With Cache Only mode the instance of C1 is in the Rete network only if it has been explicitly loaded.)
2.