[wildfly-dev] Batch Subsystem Changes

[James R. Perkins]

Hello All,
The past couple weeks I've been working on basically a redo of the batch 
subsystem. Almost the entire management model is changing to hopefully 
make it more user friendly.

In WildFly 8 and WildFly 9 the model looked like the following:

{
     "job-repository-type" => "in-memory",
     "job-repository" => {"jdbc" => {"jndi-name" => undefined}},
     "thread-factory" => undefined,
     "thread-pool" => {"batch" => {
         "keepalive-time" => {
             "time" => 30L,
             "unit" => "SECONDS"
         },
         "max-threads" => 10,
         "name" => "batch",
         "thread-factory" => undefined
     }}
}

The job-repository-type could either be jdcb or in-memory. The jndi-name 
attribute on the single job-repository=jdbc resource could be undefined 
indicating the default data-source should be used or JNDI name to look 
up the data-source with no validation being done until the user actually 
tries to deploy a batch deployment.

The thread-pool and thread-factory are the same as other resources that 
use the thread "subsystem" shared resources.

As you can see it's not very intuitive and somewhat clumsy to say the 
least. Only a single job-repository could be defined which isn't great 
for multiple deployments.

In WildFly 10 the model, at least currently, will look like:

{
     "default-job-repository" => "default",
     "in-memory-job-repository" => {"default" => {}},
     "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}},
     "thread-factory" => undefined,
     "thread-pool" => {"batch" => {
         "active-count" => 0,
         "completed-task-count" => 0L,
         "current-thread-count" => 0,
         "keepalive-time" => {
             "time" => 30L,
             "unit" => "SECONDS"
         },
         "largest-thread-count" => 0,
         "max-threads" => 10,
         "name" => "batch",
         "queue-size" => 0,
         "rejected-count" => 0,
         "task-count" => 0L,
         "thread-factory" => undefined
     }}
}

The default-job-repository will be an attribute similar to the previous 
job-repository attribute. The difference being you can use any named 
in-memory-job-repository or jdbc-job-repository. You can have any number 
of in-memory or JDBC job repositories.

The data-source attribute value on a jdbc-job-repository resource will 
use the org.wildfly.data-source [1]. The name of the data-source is used 
instead of the JNDI which is a much cleaner approach.

The thread-factory may be removed and the thread-pool may be changed to 
use attribute groups (once I figure out how to use them :)).

As part of this I considered changing the name from batch to 
batch-jberet. The main concern I had with this was the web console, but 
I seem to have broken that anyway with the changes to the model. Does 
anyone have opinions on a name change to batch-jberet?

Also parsing an old configuration may have some issues if the user was 
using a JDBC job repository. I've currently not found a good way to find 
a data-source resource name based on a JNDI name. I'm not sure if we 
should just fail when adding a legacy JDBC job repository. Any 
suggestions here would be helpful.

Any comments or concerns in general are welcome. This is our chance to 
get it right this time.


[1]: https://github.com/wildfly/wildfly/pull/7682

-- 
James R. Perkins
JBoss by Red Hat