Introducing the Scheduler Service
for Lutris EAS 4
Andy John & Klaus Krull Lutris Technologies
The Scheduler Service is the first "Technology Preview" offering
from Lutris Technologies. It serves as a code and functional level introduction,
by demonstration, to the advantages of the Lutris EAS 4 Services Architecture.
It includes a:
- Scheduler Service
- Scheduler Admin Client
The Lutris EAS Scheduler Service is a platform service that adds scheduling
capabilities to Lutris EAS. Similar to the Unix command "cron", the scheduler
manages a set of jobs as task/schedule pairs. The task tells the scheduler
what action to perform, and the schedule tells it when and how-often to
run the task. The Scheduler Service uses the Lutris EAS logging capabilities
to provide consolidated display of results and status information.
Note:
As with all field test software,
the Scheduler Service Technology Preview is not production quality.
It's licensed for field test use only and it shouldn't be used in
a production environment. |
The Scheduler Service introduces the ability to invoke tasks, according
to schedules, to the application server. Sometimes the schueduler carrieses
out the schedular task. but most of the time, the scheduler runs (execs)
a program on the host system. Maybe it calls a method on one of your other
EAS services.

The list of jobs is initially read from the config file (enhydra-service.xml),
and then persisted in the JNDI namespace. Jobs may be added or deleted
via the Scheduler Admin interface, and a subset of this API is exposed
via the MBean interface. An option to save the current settings is provided,
which saves the current settings (any changes made with the Admin Interface)
to the JNDI namespace. This allows the scheduler to restore its state
when the server is restarted.
Getting Started
To provide an overview of the Lutris EAS Scheduler Service, a number
of pre-defined sample jobs are provided. To use the Scheduler Service
and the default jobs:
- Deploy the Scheduler Service (SchedulerService.ear
file.)
- View job results in the Lutris EAS log file
(in the Lutris Management Console using the menu command 'Server
| Display Log' or on UNIX using the 'tail -f' utility on
the '<eas_root>\logs\ems.log' file.)
- Access the Scheduler Admin from a browser (default
location: http://localhost:8002/SchedulerSampleClient/Main.html)
- Start the sample jobs (the Scheduler thread)
by selecting the 'Start' button in the Scheduler Admin.
- Delete existing jobs or add new jobs using the
Scheduler Admin. (Note: the Scheduler thread does not have to be running
in order to add or delete jobs.)
Scheduler Admin
The Scheduler Admin provides an administration client (early access)
for working with jobs. The following capabilities are currently supported:
Scheduler Management:
- Start and stop the scheduler thread.
- Show the state of the scheduler thread.
Job Management:
- Display the list of active jobs
- Displays the time until the next task fires.
- Add new jobs, including tasks and schedules.
- Delete jobs
- Ability to save tasks to the namespace (ensures
tasks are available after a server restart.)

Task Types
Currently there are six task types supported by the Scheduler Service:
- Exec: Runs a program in a separate process
(uses Runtime.exec()). Note: this is often OS dependant.
- JNDI: Looks up an object via JNDI (such
as another service), and call the specified method within the object.
- MBean: Invokes an operation on an MBean.
- HTTPGet: Performs an HTTP get request
on a URL, and logs the resulting HTTP result code.
- Java: Calls a method of a Java object.
- Status: Logs status
information about the VM and EAS.
Schedule Types
Currently there are 4 schedule types supported by the Scheduler Service:
- Once: associated task will run on the
date specified. If the server starts up after this date, the command
does not fire.
- After Startup: associated task will run
the defined seconds once after the server starts up, or after the job
is added for the first time in the UI.
- Repeating Interval: associated task will
run on the interval specified (in seconds.) The task is run at startup
time, and then every interval of time.
- Date Series: associated task will run
on the defined date and then on the interval specified (in seconds.)
If an even-hour-boundary is specified for the start time, and one hour
as the interval, then the command will run exactly on the hour, regardless
of when the server starts up.

Adding Jobs
Using the Scheduler Admin UI to add jobs
(Recommended):
To add a job, select 'Add a job' from the Scheduler Admin. Each job includes
two components that must both be set: the schedule on which to run the
task, and the task to be run.
Defining the Schedule:
- When adding a Once schedule, a valid date is required (be sure
to use the supplied date format).
For example, Date: "10/26/01 12:46 PM "
(Format: MM/DD/YY HH:MM)
- When adding a DateSeries schedule, the date
and the interval are required.
For example, Date: "10/26/01 12:46 PM"; Interval:
"120000" (in seconds)
- When adding an Interval schedule, an interval
(in seconds) is required.
For example, Interval: "120000" (in seconds)
- When adding an AfterStartup schedule, the time
to wait after startup (in seconds) is required.
For example, WaitTime: "12000" (in seconds)
Defining the Task:
- When adding an Exec task, the only information required is
the command to be executed.
For example, command: "hostname"
- When adding a JNDI task, the JNDI name and the method name
are required.
For example, JNDI Name: "ems:/Services/TimeManager/manager";
Method Name: "getDate"
- When adding an MBean task, the MBean name and operation (op)
name are required.
For example, Bean Name: "WebContScope=0,webApp=Welcome";
Op Name: "getRPM_current"
- When adding an HTTPGet task, a URL is required.
For example, URL: "http://www.lutris.com
- When adding an Status task, no parameters are required.
The set of supported tasks is designed to be general-purpose and cover
as wide a scope of possible needs as possible. If a job requires a complex
task, the task code should be implemented external to the Scheduler Service
and then called from one of the pre-existing tasks in the Scheduler Service.
For example:
- For a Lutris EAS Platform Service, the code could be included
in a method that is exposed through the Services TAP, and then a JNDI
task would be used from the Scheduler to call that method.
- For a Web Application, the code could be exposed as a special
Servlet, and then an HTTPGet task would be used from the Scheduler to
access that servlet.
- For an EJB, the code could be included in a method in the EJB,
and then a JNDI task would be used from the Scheduler to call that method.
Editing the config file (recommended
for experienced users only):
While it is recommended that jobs be created using the scheduler
admin, jobs can also be added, deleted, and edited by directly manipulating
the enhydra-service.xml file. This file is found inside the SchedulerService.jar
(part of the SchedulerService.ear package), and requires the re-packaging
and re-deployment of the scheduler service to take effect.
A typical job appears as:
<property-group name="job_3"> <!-- The job id. Must be unique -->
<property name="taskType" type="java.lang.String" value="jndi"/>
<property name="jndiName" type="java.lang.String" value="ems:/Services/TimeManager/manager"/>
<property name="methodName" type="java.lang.String" value="getDate"/>
<property name="scheduleType" type="java.lang.String" value="interval"/>
<property name="interval" type="java.lang.String" value="10000"/>
</property-group>
Future Enhancements
Potential future enhancements for the Scheduler Service.
(Please provide feedback on which are most important for you.)
- Ability to activity / deactivate individual tasks.
- Improved error handling when creating tasks/schedules/jobs.
- Enhanced administration (Cleaned up UI, admin
extension to LMC, capabilities, and security.)
- Allow editing of jobs - replace the schedule or task
on the fly.
- Conditional tasks - i.e. check URL and if not 200,
then do X.
- Add more schedule types, such as EveryWeekday. Use
Calendar to check day of week etc....
- Runtime determined parameters. Such as a special code
that means "the date right now" or the "hostname".
- Provide additional logging capabilities, such as option
to assign a task it's own log channel.
- Allow user to force task to run.
- Log the last N tasks that were run.
- Ability to 'deploy' a task.
We are especially interested in these areas for your feedback:
- How you are or would like to use the SMS Service
- Functionality of existing capabilities
- What SMS service provider (if any) are you currently
using? What interfaces/APIs to they expose to let you send messages?
- Favorite items from the 'Future Enhancements' section
- General comments and suggestion
|