The optional entry points described in this section are invoked only for scripts with the persistent execution mode. They are invoked at the appropriate times to help the script with managing resources that persist across invocations of the regular execution entry points described above.
If the script has the persistent execution mode, this optional entry point is invoked to allow the script to initialize any persistent resources it may need. The entry point is called "lazily", that is, it's invoked only when Switch receives the first processing request for a script instance of this type after startup or after the most recent finalize or abort.
The entry point returns true if initialization was successful and false if it is not able to initialize appropriately. In the latter case Switch marks all script instances of this type as a problem process and it retries initialization at regular intervals. As long as initialization fails, Switch refrains from invoking jobArrived and timerFired for the script.
If the entry point is absent, this means the script does not need initialization and the entry point is assumed to return true.
If the script has an execution mode other than persistent this entry point is never invoked.
If the script has the persistent execution mode, this optional entry point is invoked to allow the script to release any persistent resources it may have used. The entry point is called when Switch stops processing and whenever Switch determines that it is meaningful to do so – for example, after the script fails a job.
If the entry point is absent, this means the script doesn't need finalization.
If the script has an execution mode other than persistent this entry point is never invoked.
If the script has the persistent execution mode, this optional entry point is invoked to allow the script to release any persistent resources after its execution was forcefully aborted due to a time-out.
If the entry point is absent, this means the script does not need cleanup.
If the script has an execution mode other than persistent this entry point is never invoked.
In persistent execution mode, the invocation sequence is as follows:
( initializeProcessing ( jobArrived | timerFired )+ finalizeProcessing )*
In other words, initialize and finalize bracket one or more processing requests for any script instance of this execution group. All of these invocations happen in the same thread so that the contents of the global variable "persistent" is preserved. Thus, for example, the script can start an external application in the initialize entry point and leave it running until finalize, while maintaining a persistent reference to the application for use in intermediate invocations. Switch guarantees the appropriate invocation sequence, so the script does not need to worry about this.
There is one important exception to this guaranteed invocation sequence. If one of the involved entry points (initializeProcessing, jobArrived, timerFired and finalizeProcessing) does not return within the maximum allotted time ("abort processes after" in error handling preferences), Switch aborts the thread and releases all resources attached to it, including its private scripting environment. Finally, Switch invokes the cleanupAfterAbort entry point to allow the script to release any external resources.
Unfortunately the cleanupAfterAbort function can no longer access the script's private persistent data since it is being called in a new thread (the old one was just destroyed). Communication between the regular functions and the cleanup function is possible through the global data access functions of the Environment class, but this is restricted to plain strings (rather than arbitrary objects).
After aborting a thread as described, Switch restarts the regular invocation sequence in a new thread whenever it receives a new processing request.
The entry points related to application discovery/licensing and property validation are invoked in the same thread (and thus can access the global variable "persistent") but they are not automatically bracketed by initializeProcessing and finalizeProcessing. If required, these entry points must handle initialization and finalization themselves.