The cartridge agent is a component that resides within a cartridge instance and handles the communication between the cartridge and Stratos. This component is implemented using Java and Python. The cartridge agent communicates with the message broker (MB), Complex Event Processor (CEP), Business Activity Monitor (BAM) and the remote Git repository as depicted in the diagram below:
The cartridge agent is generic and can be used in any cartridge. A cartridge agent comprises of the following components as illustrated in the following diagram: Instance Notifier Event Receiver, Health Statistics Publisher, Artifact Distribution/Artifact Update event and Instance Status Event Publisher. For more information on what Cartridge Agent does and the protocols it uses to communicate with components, see Cartridge Agent Lifecycle.
The use of the other components in cartridge agent have been explained as follows:
InstanceCleanupClusterEvent. Its main responsibility is to clone, pull, push artifacts between a specified remote Git repository. This component is only activated for Cartridge instances that already has a configured repository URL.
In addition, Cartridge Agent has some extension points: Instance Started Extension, Start Servers Extension, Artifacts Updated Extension, Instance Activated Extension and Clean Extension. Cartridge developers can use these extension points to extend the cartridges in Apache Stratos. For example, the Instance Started Extension can be used to customize the cartridge at the point an instance has started.
When communicating with the Message Broker, the Python Cartridge Agent (PCA) will go through the provided URL list and connect to the first broker that is available.
The listening subscriber client always ensures to maintain a connection with one of the brokers. The PCA periodically checks if the connected Message Broker is in fact alive or not. If the connected broker goes down, the PCA will go through the Message Broker list and select the first available broker. If none of the provided message brokers are online, the subscribing client will keep retrying until one broker becomes available. This logic is separately executed for each topic subscription.
The publishing client will publish the events to the first broker available. If none of the brokers are available it will keep retrying to publish the event, until the provided
mb.publisher.timeout value is exceeded. The default value for this is 15 minutes. After the latter mentioned timeout, if the event is still unpublished, the event is dropped.
It is possible for the events to be published to one broker and for the intended consumers to be connected to another broker. However, if the Master/Slave deployment is done correctly, data sharing happens without an issue and this situation is not of any concern.