Kohei Nozaki's blog 

Entries tagged [jberet]

Multiple deployment use mode is implemented to jberetweb

Posted on Thursday Jan 15, 2015 at 09:06PM in jberetweb

Now jberetweb can operate (start, stop, etc) distributed batches in multiple deployment. to enable multiple deployment use mode, suppress -DjobOperator.jndi and specify -DjobOperator.name=${facade-class-name} (e.g. JobOperatorFacade) in mvn option when you build it.

In multiple deployment use mode, "App Name" column will be added for grasp where is deployment of each job comprehensively. actions such as restart, stop will be executed through lookup of appropriate remote EJB interface in according to "App Name".

8eb794ca c389 4590 bc0a 643507e66c3a

Also in Start Job window, "App Name" can be specified. this will lookup appropriate remote interface accordingly too.

905367a9 1944 4025 bf2c 0623571313b0

Index needed on jobexecutionid column in step_execution table

Posted on Monday Jan 05, 2015 at 09:56PM in jberetweb

Today I deployed new jberetweb to my production system which have 1 million rows in step_execution table, and felt jberetweb slow. I looked it and found the cause is sequential scan.

jbatch=# explain analyze select * from step_execution where jobexecutionid = 384846;
                                                    QUERY PLAN                                                    
 Seq Scan on step_execution  (cost=0.00..36817.53 rows=4 width=626) (actual time=101.046..101.047 rows=2 loops=1)
   Filter: (jobexecutionid = 384846)
   Rows Removed by Filter: 1102459
 Total runtime: 101.074 ms
So I created an index on jobexecutionid column in step_execution table, then jberetweb starts running fast.
jbatch=# create index step_execution_jobexecutionid_idx on step_execution (jobexecutionid);
jbatch=# explain analyze select * from step_execution where jobexecutionid = 384846;
                                                                     QUERY PLAN                                                                     
 Index Scan using step_execution_jobexecutionid_idx on step_execution  (cost=0.43..8.50 rows=4 width=626) (actual time=0.054..0.056 rows=2 loops=1)
   Index Cond: (jobexecutionid = 384846)
 Total runtime: 0.113 ms
Maybe more indexes are needed for default JBeret schema if I implement some filtering function to jberetweb.

Job operation features are implemented to jberetweb

Posted on Sunday Jan 04, 2015 at 09:26PM in jberetweb

Now jberetweb is able to operate JobOperator interface through remote EJB invocation, so finally jberetweb can start batch jobs. the Start Job window popups when "Start Job" anchor is clicked on the upper right corner. here's a screenshot:

スクリーンショット 2015-01-04 20.53.13

To use this feature, some preparation are needed. first, you have to expose a remote EJB interface of javax.batch.operations.JobOperator from your batch application archive. an example of simplest one is available here. also entire of the project is here.

You can just put this class to any package in your batch application archive. after that, you can see some notification of JNDI names in your WildFly console at every deployment like this:

21:06:45,501 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-10) JNDI bindings for session bean named JobOperatorFacade in deployment unit deployment "jbatchtest-1.0-SNAPSHOT.war" are as follows:


Then save first one of yours ("java:global/jbatchtest-1.0-SNAPSHOT/JobOperatorFacade!javax.batch.operations.JobOperator" for example), then put that string to a build parameter of jberetweb (after "-DjobOperator.jndi="). please refer "How to use" section of README.md for build instruction.

Other operations such as restart, stop, abandon are implemented too so I will write more about it later. jberetweb can be obtained from GitHub.

jberetweb, JBeret job repository viewer

Posted on Friday Jan 02, 2015 at 01:01AM in jberetweb

What are JBeret and jberetweb?

JBeret is out-of-box JSR352 JBatch implementation of the WildFly application server. it manages its statuses of jobs and steps in several types of data storage like RDBMS, which called repository, but it has no management console or even standardized way to see it efficiently (I've been watching the repository through SQL!). so I created jberetweb as a small web application which shows JDBC job repository of JBeret.

jberetweb can be obtained at GitHub.

スクリーンショット 2015-01-01 23.31.18

What can be done with jberetweb?

It shows recent Job Executions with its name, start/end time and batch status on the table at upper half of the page. these rows are clickable. additional information like Job Parameters and Step Executions will be shown when any rows of Job Executions table is clicked. Execution Exception data will be shown if step has failed due to exception occured. any problematic rows such as failed execution or step are came with highlighting. thanks to JSF's partial rendering and Ajax, paging and operations are fast.

How do I install it?

As I described at README.md in GitHub repository of it, you have to clone and build it with mvn yourself, and some configuration is needed for WildFly before deploy the WAR.

  • Create a database on PostgreSQL (jberetweb should run on any other RDBMS, but I haven't tested yet)
  • Register a XA data source for job repository
  • Register JNDI name of JDBC job repository
  • Set job repository type to JDBC
  • Define JSF project stage to JNDI
Configuration procedures with jboss-cli should be like this:
xa-data-source add \
      --name=JBatchDS \
      --driver-name=postgresql \
      --jndi-name=java:jboss/jdbc/JBatchDS \
      --user-name=postgres \
/subsystem=batch/job-repository=jdbc:write-attribute(name=jndi-name, value=java:jboss/jdbc/JBatchDS)
/subsystem=batch:write-attribute(name=job-repository-type, value=jdbc)


  • JBeret creates schema automatically if any tables aren't found so make sure to use database user who can execute DDLs.
  • Use XA datasource for both of job repository and your application database.


I'm trying to find a way to execute jobs from jberetweb but it shouldn't be easy due to JSR352's spec. so job artifacts should be packed with its job controller, but it makes jberetweb unportable. some options are available such as use EAR for the application. it can be deployed jberetweb.war separately. another one is use of remote EJB invocation. put simple JobOperator facade implementation which annotated @Remote interface to an application archive and deploy it, then lookup and invoke @Remote interface from jberetweb. I think the latter is better, but supporting both options wouldn't be difficult much.

Here's some related pointers:

I would be glad if you do any feedback to me because it's my first developed software became public on GitHub.