Developing Apama Applications > Developing Apama Applications in EPL > Defining Event Listeners > Understanding time in the correlator
Understanding time in the correlator
When the correlator receives an event, it gives the event a timestamp that indicates the time that the correlator received the event. The correlator then places the event on the input queue of each public context. The correlator processes events in the order in which they appear on each input queue.
An input queue can grow considerably. In extreme cases, this might mean that a few seconds pass between the time an event arrives and the time the correlator processes it. As you can imagine, this has implications for whether the correlator triggers actions. However, the correlator uses event timestamps, and not real time, to determine when to trigger actions.
As an extreme example, suppose a monitor is looking for A -> B within(2.0). The correlator receives event A. However, the queue has grown to a huge size and the correlator processes event A three seconds after it arrives. The correlator receives event B one second after it receives event A. Some events in the queue before event B cause a lot of computation in the correlator. The result is that the correlator processes event B five seconds after event B arrives. In short, event B arrives one second after event A, but the correlator processes event B three seconds after it processes event A.
If the correlator used real time, A -> B within(2.0) would not be triggered by this pattern. This is because the correlator processes event B more than two seconds after processing event A. However, the correlator uses the timestamp to determine whether to trigger actions. Consequently, A -> B within(2.0) does trigger, because the correlator received event B one second after event A, and so their timestamps are within 2 seconds of each other.
As you can see, the size of an input queue never affects temporal comparisons.
As mentioned before, when an event arrives, the correlator assigns a timestamp to the event. The timestamp indicates the time that the event arrived at the correlator. If you coassign an event to a variable, the correlator sets the timestamp of the event to the current time in the context in which the coassignment occurs.
The correlator uses clock ticks to specify the value of each timestamp. The correlator generates a clock tick every tenth of a second. The value of an event’s timestamp is the value of the last clock tick before the event arrived.
When you start the correlator, you can specify the --frequency hz option if you want the correlator to generate clock ticks at an interval other than every tenth of a second. Instead, the correlator generates clock ticks at a frequency of hz per second. Be aware that there is no benefit in increasing hz above the rate at which your operating system can generate its own clock ticks internally. On UNIX and some Windows machines, this is 100 Hz and on other Windows machines it is 64 Hz.
When you start the correlator, you can specify the -Xclock option to disable the correlator’s internal clock and replace it with externally generated time events. See also Generating events that keep time.
Copyright © Software AG, Darmstadt, Germany and/or Software AG USA Inc., Reston, VA, USA, and/or its Subsidiaries and or/its Affiliates and/or their licensors.
Use, reproduction, transfer, publication or disclosure is prohibited except as specifically provided for in your License Agreement with Software AG.