Apama 10.3.1 | Apama Documentation | Developing Apama Applications | Developing Apama Applications in EPL | Defining Monitors | Spawning monitor instances | Sample code for spawning
 
Sample code for spawning
EPL that implements the example described in How spawning works is as follows:
// The following event type defines a stock that a user is interested
// in. The event type includes the name of the stock (name) and the
// user's personal name (owner).
//
event NewStock {
   string name;
   string owner;
}
 
event StockTick {
   string name;
   float price;
}
 
monitor SimpleShareSearch {
   NewStock chosenStock;
   integer numberTicks;
   StockTick newTick;
 
   // Listen for all NewStock events. When a NewStock event is found
   // assign it to the chosenStock variable and spawn with a call to
   // the matchTicks() action. This clones the state of the monitor
   // and launches a monitor instance that executes matchTicks().
   action onload() {
     numberTicks := 0;
     on all NewStock (*, *):chosenStock spawn matchTicks();
   }
 
   // In the spawned monitor instance, listen for only those StockTick
   // events whose name matches the name in the chosenStock variable.
   action matchTicks() {
     on all StockTick(chosenStock.name,*):newTick processTick();
   }
 
   action processTick() {
     numberTicks := numberTicks + 1;
     log "A StockTick regarding the stock "
       + newTick.name + "has been received "
       + numberTicks + " times. This is relevant for "
       + " Trader name: " + chosenStock.owner
       + " and the price is " + newTick.price.toString() at INFO;
       + ".";
   }
}
This example defines a new event type named NewStock. Traders dispatch this event when they want to look for a specific kind of stock event. The code example spawns a monitor instance when the monitor finds a NewStock event. For example, if three newStock events are received by the initial monitor instance, there will be three spawned monitor instances. Other than spawning, the difference between this code sample and the sample in Example of a simple monitor is that this one specifies an owner in each NewStock event and the monitor's state now includes a counter.
In this example, after spawning, all processing is within a spawned monitor instance. Processing begins with execution of the matchTicks action. This action starts by defining an event listener for StockTick events whose name field matches the name field in the spawned monitor instance's chosenStock variable. When there are multiple, spawned monitor instances, each spawned monitor instance listens for only the StockTick events that match their chosenStock name.
The numberTicks counter variable and the chosenStock event variable, which contains the stock name and the owner's name, are available in the cloned state of the spawned monitor instance. This lets the processTick() action in each spawned monitor instance
*Customize output to include the originating trader's name
*Maintain a counter of how many StockTicks for a particular stock have been detected for a trader
The really important aspect that distinguishes spawning is that the entire variable space is cloned at the moment of spawning. In the example, every spawned monitor instance has a copy of the chosenStock variable that contains the NewStock event that triggered spawning. Also, every spawned monitor instance has a copy of the numberTicks variable, which is always set to 0 when the initial monitor instance spawns. This ensures that each spawned monitor instance can maintain an accurate count of how many matching StockTick events have been found.
The initial monitor instance listens for NewStock events. Remember that spawning does not clone active listeners, so the spawned monitor instances do not have listeners that watch for NewStock events. Each spawned monitor instance listens for only those StockTick events that contain name fields that match that spawned monitor instance's value for the chosenStock variable.
Typically, spawning is not an expensive operation. However, its overhead does increase as the size of the monitor being spawned increases. When writing an EPL application avoid repeated spawning of monitors that contain a large number of variables.
Spawned monitor instances contain copies of all global state from the spawning monitor instance. It does not matter whether the spawned monitor instance is going to use that state or not. To avoid wasting memory, a typical practice is to hold state in events that are referred to by local variables, which are not copied during spawning. This ensures that you do not have a lot of state information in global variables when the monitor instance spawns. Alternatively, you can insert code so that the new monitor instance clears unneeded state immediately after it starts running.
For information about spawning to actions that are members of events, see Spawning.

Copyright © 2013-2019 | 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.