[wildfly-dev] Batch Subsystem Changes

[Jason T. Greene]

Actually in this case you could support both the old and the new subsystem as its a one to one mapping. Then you do not need the migration bit.

Sent from my iPhone

> On Jul 6, 2015, at 8:02 PM, Jason T. Greene <jason.greene at redhat.com> wrote:
> 
> IMO we should avoid breaking compatibility unless there is no other option. If we do break compatibility we should rename the subsystem and provide a migration operation.
> 
>> On Jul 6, 2015, at 2:13 PM, James R. Perkins <jperkins at redhat.com> 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
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev