Generating events with the route statement
The route statement generates a new event that goes to the front of the input queue of the current context.
Any active listeners seeking that event then receive it. There is only one difference between an externally sourced event (passed in through a live message feed) and an event that was generated internally through a
route statement. The difference is that internally routed events are placed at the front of the context's input queue in the same order as they are routed within an action, and after any previously internally routed events where multiple listener actions have been triggered by an event. The correlator processes the routed events on the input queue before it processes the next non-routed event on the input queue. See
Event processing order for monitors.
For example:
action simulateCrash() {
route StockTick(currentStock.name, 50.0);
route StockTick(currentStock.name, 30.0);
route StockTick(currentStock.name, 20.0);
route StockTick(currentStock.name, 10.0);
route StockTick(currentStock.name, 5.0);
route StockTick(currentStock.name, 1.0);
}
The simulateCrash() action shown above routes six StockTick events for the monitor's specific stock name, with drastically reducing prices. Other monitors (or the same monitor) may receive these events and process them accordingly.
The route statement can operate on any values as well as events, provided that the any value is of a routable event type.
You cannot route an event if the event (or one of its members) contains a field of an unroutable type (action, chunk, listener, stream). There is a runtime check if the event (or one of its members) can contain an any field; an exception is thrown if the any field contains an object of type action, chunk, listener, or stream.
Note that you can route an event whose type is defined in a monitor.