Catalyst

requirements

definitions

The purpose of the Catalyst Job Queue is to allow the application to run code in the absence of an HTTP request. The code run this way is called a job. The act of determining the moments in time the job runs is called scheduling. We distinguish between the code that is supplied by the framework itself, called system code and the code provided by the developer for each application in part, called user code.

categories

A job can be scheduled to run periodically (a cron job) or one single time (an at job). The schedule of a job can be set up at application startup time (a application-scheduled job) or by a certain HTTP request (a user-scheduled job).

principles

There should be no extra user code required (and if possibly, no system code apart from the JobQueue engine) to run a job. Therefore the code involved in executing a job should be a logical unit of code that can normally be executed by the application. The logical unit of code most suitable for this purpose is the one executed in response to an HTTP request.

Therefore we narrow the definition of a job to: a logical unit of code that is run in response to an HTTP request.

Furthermore, we observe that in the case of user-scheduled jobs, the job itself is scheduled by such an unit and recognize that in this case a job could also be construed to be just the remaining part of the scheduling unit of code.

In conclusion, we redefine the job as a logical unit of code normally executed by the application in response to an HTTP request or a part of such a unit.

jobs

request jobs

A request job is any whole unit of code that can be run by the the application in response to a HTTP request.

Since the Job Queue's purpose is to run this code in the absence of such a request and the code is designed to run in response to a request, it follows that the Job Queue must provide a fake request to the job.

The unit of code will eventually generate a response document, which will normally be sent to the agent who has initiated the HTTP request. Unfortunately, in the case of a job, the agent is not directly available, therefore the Job Queue must save the response (possibly also analyzing and acting upon it) and be able to deliver this response upon request.

continuation jobs

A continuation job is the part of a unit of code that can be run by the application as a continuation. A unit of code can store the state of the application into a session, creating a so-called continuation. This continuation allows the Job Queue to restore the state of the application and continue the execution at a later point in time.

Since the originating unit of code did have an actual HTTP request available to initiate it, the Job Queue must not simulate a request for this kind of job.

However, the above-metioned problem of response delivery still remains.

functionality

From the previous discussion we conclude that a Job Queue Engine must:

• be able to simulate an HTTP request based on a certain configuration
• be able to properly handle the response, namely, store it, deliver it and even analyze and act upon it (for ex. unschedule the job in case of execution failure)
• ensure the scheduling and unscheduling of a job either by configuration or by user request

last updated 1 year ago #