Execution

As previously stated, modules execute in response to the arrival of data. Modules that take no inputs are enabled when itinerary execution begins.

In the case of modules other than user interface and visualization modules, there is one entry point method that takes no inputs and returns no values. Here is the definition:

  protected void doit() throws Exception;

This method is protected, and throws an Exception. More on error handling in another section, but it is important to understand that the D2K infrastructure will handle exceptions.

There are methods to pull inputs and to push outputs. These methods should never be called form outside the doit method! The flow of data provides important information to the infrastructure that is used in the management of itinerary execution. The infrastructure expects data to flow only during execution of the doit method. The methods are defined as follows:

  protected Object pullInput(int index);
  protected void pushOutput(Object output, int index);

The pullInput() method will return the next item available in the pipe. It takes the index of the pipe to pull the input from. If there is nothing in the pipe, it will return null, but this method should not be called if nothing is in the pipe. Before we call pullInput, we should have checked the flags to ensure there was something in the pipe using the getFlags() method.

The pushOutput method's arguments include the object to push into the pipe, and the index of the pipe to use. It is also expected that the module will push only one output per pipe for each invocation of the doit method. The infrastructure manages itinerary execution by scheduling modules to run efficiently -- if a module pushes more than one output per pipe during an execution cycle, there is no opportunity for the infrastructure to deschedule a module so that others may execute, and as the contents of the pipe grow, the memory footprint increases until the module exits, or runs out of memory.