2:13 p.m.
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