How Can We Help?
When a streamConsists of a combination of Stream Objects allowing real-time data to flow through. It is created to address a particular use case. is published on a host, each of its stream objects load their relevant agent resource files into memory so they can begin running. To prevent errors from different versions of the same file being used and to ensure as much as possible that stream objects do not share any form of state, they are loaded in an isolated manner – separate from the application and other resource files, with requests for other resources being intercepted and supplied by the host only as needed.
This process also removes some contextual information which would otherwise be available to each resource, such as its location in the file directory, but this is usually not a problem. However, some resources may rely on this information to provide their functionality. In these cases, the stream objectIs a reusable component that functions as a building block for a stream. There are different types available: action agents, listeners, transformations, context providers and functions. must load its resource files in a different manner that preserves the necessary contextual information at the cost of risking errors.
This decision is made when packaging the agent using the XMPro Stream Integration Manager. On the initial Agent description page and next to the text box for Entry Point is the checkbox for Isolated Loading.
Leaving this box checked will tell the stream hostIs a client application which hosts/executes the Use Cases designed by the user in the IoT Portal. that your agent does not require any contextual information from its resource files and should not share static state with its other instances. Unchecking this box will tell the stream host that the resource should be loaded into a shared memory space with all its contextual information left intact.
Avoiding errors due to non-isolated agents
The main source of possible errors in non-isolated agents comes from loading the same resource twice from two different agents into a stream host. These errors will prevent any stream containing the later agents from starting, and can arise both from two different non-isolated agents referencing the same resource or by two different versions of the same agent doing the same. The same version of an agent running twice will not throw an error.
This can be avoided by designing and allocating your streams to ensure that two non-isolated agents with similar resources never run on the same collectionIs a virtual grouping of Stream Hosts. All Stream Hosts in a collection are broadcasted the same instructions from the IoT Portal. This way a Use Case can be mass deployed to all the Stream Hosts in a given Collection.. If you need to update a stream object to a later version of a non-isolated agent or want to switch to running another non-isolated agent altogether, any streams containing the initial agent must be unpublished and all stream hosts in that collection to remove all traces of the first agent from memory restarted before the new stream has been published.
Comments are closed.