The flow of execution of Java applications through the correlator at any given time is single threaded. All the listeners of Java applications are fired in a single-threaded manner. However, during the lifetime of a Java application, its execution may be moved among a number of threads by the correlator. This is particularly important since thread-local variables will not behave in the same way as you would expect them to in a conventional Java application.

When a number of monitor classes are loaded into the JVM within the correlator their onLoad methods are executed in turn, in the same order as the injected classes, and any listeners created are set up and activated.

Control then reverts to the correlator, which takes in one event from its input queue. This event is examined by each of the active listeners in turn (the order is undefined), and each one that triggers immediately calls the match() method in its registered MatchListener object.

Once all the listeners have processed the event (and hence all match methods terminated), control reverts to the correlator to process the next input event. Note that since events can also match listeners in EPL monitors, these would also be processed before control reverts.

However, Java applications can create other Java threads. In such multi-threaded Apama Java applications, the correlator has no control of these additional Java threads. Consequently, you should never route or emit an event from a Java thread that was not the thread in which the correlator invoked the Java application. Doing this results in unpredictable behavior. To communicate from your Java application to other parts of the correlator, use the enqueue() method or preferably, the enqueueTo() method.