[wildfly-dev] Batch Subsystem Changes

[James R. Perkins]

I've got the initial work done for this now [1] (only the last commit). 
It still needs to be determined how a legacy configuration with a JDBC 
job repository will work. The legacy configuration used a JNDI name 
which won't work with the data source capabilities. If anyone has ideas 
here that would be helpful.

I didn't do any work to support both subsystems running side-by-side. If 
that's something that should be done I think it would be fairly easy to do.

[1]: https://github.com/wildfly/wildfly/compare/master...jamezp:WFLY-4811

On 07/06/2015 12:13 PM, James R. Perkins wrote:
> 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