Lifetime of connectivity plug-ins
Connectivity plug-ins listed in chains under the startChains section of the configuration file for connectivity plug-ins undergo the following lifetime events.
At correlator startup:
Class is loaded using the
classpath or
libraryName.
Class is constructed using the
(Map, String, Logger) constructor for Java classes, or the
(const std::string &, const std::string &, const map_t &) constructor for C++ .
hostSide and
transportSide members are set.
All codecs in a chain have the
start() method called.
The transport has the
start() method called.
If any of the above throw an exception, that will be logged as an error and the correlator will fail to start. These methods should complete quickly; delays here will delay the correlator starting up. Blocking or long running operations should be handled by a separate thread.
After start() is called on all members of the chain, events may flow through the chain in either direction (if an EPL application is emitting events to the chain, they will be delivered as messages and delivered through the codecs towards the transport). The transport is permitted to send events hostwards, but they will be queued by the correlator until the application is ready for them.
Soon after the EPL application has been injected (and, if necessary, it has performed initialization), the EPL application should call ConnectivityPlugins.onApplicationInitialized(). At this point:
hostReady() is called on every codec.
hostReady() is called on the transport.
If any of the above throw an exception, that will be logged as an error and the chain will be disconnected. These methods should complete quickly; delays here will delay the EPL application. Blocking or long running operations should be handled by a separate thread. Any events previously sent to the host will now be delivered, but the order of all events from a chain will be maintained.
When the correlator is shut down (for example, via engine_management -s), chains will be stopped:
shutdown() is called on the transport.
shutdown() is called on every codec.
Shutdown is responsible for unblocking any threads that may be blocking. For example, if a transport is delivering events by sending data over a socket, then the socket should be closed, which should unblock any threads calling into the transport and writing to the socket's streams. A plug-in may still have events sent into it after shutdown has been called; the plug-in is free to discard these events, but should not crash.
Note: | For C++ plug-ins only: the plug-in object of each plug-in is destroyed, so the plug-in class's destructor (if defined) is called. No events should be flowing through a chain at this point. |
Exceptions thrown from any of sendBatchTowards, transformEvent or deliverEvent will be logged and not propagated to their callers. Exceptions are not a suitable means to provide information between plug-ins as they are ambiguous if a large batch of events are being processed, and some codecs may choose to send events on a separate thread. Use messages to send such events; these can be null payload with information stored in the metadata, in which case most codecs will ignore the messages and pass them through.
