Name | Modified | Size | Downloads / Week |
---|---|---|---|
jcs-ear-0.1.8-SNAPSHOT.ear | 2017-06-07 | 2.0 MB | |
jcs-ear-0.1.7-SNAPSHOT.ear | 2017-05-11 | 2.0 MB | |
jcs-ear-0.1.6-SNAPSHOT.ear | 2017-04-09 | 2.1 MB | |
README.md | 2017-04-05 | 2.5 kB | |
jcs-ear-0.1.3-SNAPSHOT.ear | 2017-03-26 | 2.1 MB | |
jcs-ear-0.1.2-SNAPSHOT.ear | 2017-03-22 | 2.0 MB | |
Totals: 6 Items | 10.3 MB | 0 |
Jobbie JCS
Jobbie JCS is a jsf based web frontend to monitor batch jobs managed by JBeret (a JSR-352 implementation). Jberet needs to be configured using a jdbc job store (see https://github.com/jberet/jberet-user-guide/blob/master/set_up_jberet/README.md). Because JBeret is the default Jbatch implementation running in the Wildfly AS you can easily deploy the Jobbie ear into a Wildfly AS.
Usage
- download latest version of jobbie ear (e.g. jcs-ear-0.1.4-SNAPSHOT.ear)
- create a datasource named
java:jboss/datasources/jcsDS
aiming to the JBeret database schema - deploy the Jobbie ear into your Wildfly AS
- the registered web context for user interface is
/jobbie
(e.g. http://localhost:8080/jobbie)
User Interface
- filter jobs by date, number of hours from now and batch status
- apply filter changes by hitting the "Apply" command button
- the button right to the "Apply" button can activate a smart view (see below)
Smart view
The smart view does the following:
- refreshs the displayed job list frequently
- marks deamon job with a '@' sign behind it's name (deamon jobs are high frequently running jobs)
- only non deamon jobs, failed deamon jobs and the last succeeded deamon job are displayed
To disable Smart view hit the smart view button again.
Performance
For huge job repositories hosting high frequently running jobs it is recommended to create some database indexes like this:
create index i_job_instance_1 on job_instance (jobname);
create index i_job_execution_1 on job_execution (jobinstanceid);
create index i_job_execution_2 on job_execution (starttime, endtime);
create index i_job_execution_3 on job_execution (starttime desc, endtime desc);
create index i_step_execution_1 on step_execution (jobexecutionid)
create index i_partition_execution_1 on partition_execution (stepexecutionid)
Maintenance
In addition to be able to easily clean up old job data from your database you can add the following constraints deleting referencing data in cascade.:
alter table job_execution add constraint fk_job_instance foreign key (jobinstanceid) references job_instance (jobinstanceid) on delete cascade;
alter table step_execution add constraint fk_job_execution foreign key (jobexecutionid) references job_execution (jobexecutionid) on delete cascade;
alter table partition_execution add constraint fk_step_execution foreign key (stepexecutionid) references step_execution (stepexecutionid) on delete cascade;