Open topic with navigation

TIBCO BusinessEvents® Enterprise Edition 6.3.1

# 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 workload 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.

Note: 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 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.

Any agent that uses scorecards, and also uses Cache or Store OM, must be assigned a unique key so that the correct scorecard can be retrieved from the cache or store. The key is set in the Processing Unit tab of the CDD.

Note: By default the key is empty. When you start multiple InferenceAgents with same key, the scorecard will be shared by those 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.

Note: Do not use scorecards as a mechanism to share data between multiple agents. Consider using concepts instead.

## 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.

Did you find this helpful?

YesNo
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO BusinessEvents® Enterprise Edition

Copyright © 2004-2024. Cloud Software Group, Inc. All Rights Reserved.