7. The lifecycle of a Spring Cloud Task

7. The lifecycle of a Spring Cloud Task
Prev	Part III. Features	Next

In most cases, the modern cloud environment is designed around the execution of processes that are not expected to end. If they do, they are typically restarted. While most platforms do have some method to execute a process that isn’t restarted when it ends, the results of that execution are typically not maintained in a consumable way. Spring Cloud Task brings the ability to execute short lived processes in an environment and record the results. This allows for a microservices architecture around short lived processes as well as longer running services via the integration of tasks by messages.

While this functionality is useful in a cloud environment, the same issues can arise in a traditional deployment model as well. When executing Spring Boot applications via a scheduler like cron, it can be useful to be able to monitor the results of the application after it’s completion.

A Spring Cloud Task takes the approach that a Spring Boot application can have a start and an end and still be successful. Batch applications are just one example of where short lived processes can be helpful. Spring Cloud Task records lifecycle events of a given task.

The lifecycle consists of a single task execution. This is a physical execution of a Spring Boot application configured to be a task (annotated with the @EnableTask annotation).

At the beginning of a task (before any CommandLineRunner or ApplicationRunner implementations have been executed, an entry in the TaskRepository is created recording the start event. This event is triggered via SmartLifecycle#start being triggered by Spring Framework. This indicates to the system that all beans are ready for use and is before the execution of any of the CommandLineRunner or ApplicationRunner implementations provided by Spring Boot.

	Note
	The recording of a task will only occur upon the successful bootstrapping of an `ApplicationContext`. If the context fails to bootstrap at all, the task’s execution will not be recorded.

Upon completion of all of the *Runner#run calls from Spring Boot or the failure of an ApplicationContext (indicated via a ApplicationFailedEvent), the task execution is updated in the repository with the results.

	Note
	At the completion of a task (all `*Runner#run` methods are called and the task repository has been updated) the `ApplicationContext` will be closed by default. This behavior can be overriden by setting the property `spring.cloud.task.closecontext_enable` to false.

7.1 The TaskExecution

The information stored in the TaskRepository is modeled in the TaskExecution class and consists of the following information:

Field	Description
`executionid`	The unique id for the task’s execution.
`exitCode`	The exit code generated from an `ExitCodeExceptionMapper` implementation. If there is no exit code generated, but an `ApplicationFailedEvent` is thrown, 1 is set. Otherwise, it’s assumed to be 0.
`taskName`	The name for the task as determined by the configured `TaskNameResolver`.
`startTime`	The time the task was started as indicated by the `SmartLifecycle#start` call.
`endTime`	The time the task was completed as indicated by the `ApplicationReadyEvent`.
`exitMessage`	Any information available at the time of exit. This can programatically be set via a `TaskExecutionListener`.
`errorMessage`	If an exception is the cause of the end of the task (as indicated via an `ApplicationFailedEvent`), the stack trace for that exception will be stored here.
`arguments`	A `List` of the string command line arguments as they were passed into the executable boot application.

7.2 Mapping Exit Codes

When a task completes, it will want to return an exit code to the OS. If we take a look at our original example, we can see that we are not controlling that aspect of our application. So if an exception is thrown, the JVM will return a code that may or may not be of any use to you in the debugging of that.

As such, Spring Boot provides an interface, ExitCodeExceptionMapper that allows you to map uncaught exceptions to exit codes. This allows you to be able to indicate at that level what went wrong. Also, by mapping exit codes in this manner, Spring Cloud Task will record the exit code returned.

If the task is terminated with a SIG-INT or a SIG-TERM, the exit code will be zero unless otherwise specified within the code.

	Note
	While the task is running the exit code will be stored as a null in the repository. Once complete the appropriate exit code will be stored based on the guidelines enumerated above.