[wildfly-dev] Batch Subsystem Changes

[James R. Perkins]

Yeah that's definitely an option. One of the biggest issues with the 
current model is the JNDI name can't be validated.

In a perfect world I'd definitely not like to change the model. However 
my original design of the model was rather poor. Since there will be 
other subsystems changing in WildFly 10 I thought now would be the right 
time to break if we're going to break it at all.

On 07/06/2015 06:05 PM, Jason T. Greene wrote:
> 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

-- 
James R. Perkins
JBoss by Red Hat