[wildfly-dev] Batch Subsystem Model

[David M. Lloyd]

On 09/12/2013 11:02 PM, James R. Perkins wrote:
>
> On 09/12/2013 08:48 PM, David M. Lloyd wrote:
>> On 09/12/2013 10:39 PM, James R. Perkins wrote:
>>> I'm struggling a bit come up with the right model for the batch
>>> subsystem. The XML currently looks like the following, but doesn't have
>>> to remain like this if someone has a better idea.
>>>
>>> <subsystem xmlns="urn:jboss:domain:batch:1.0">
>>>         <job-repository value="default"/>
>>>
>>>         <job-repository-type name="default">
>>>             <in-memory thread-pool-name="default"/>
>>>         </job-repository>
>> End tags
>>
>>>         <job-repository-type name="jdbc">
>>>             <jdbc thread-pool-name="default">
>> I don't recall if we use -name suffixes in referential attributes.  I
>> don't think we do.
> That's what EJB had. You define a thread-pool then on like service=async
> there is a thread-pool-name attribute. I don't really care either way, I
> was just trying to make it consistent.
>>
>>>                 <datasource jndi-name="java:jboss/datasources/ExampleDS"/>
>>>             </jdbc>
>>>         </job-repository>
>>>
>>>         <unbounded-queue-thread-pool name="default">
>>>             <max-threads count="10"/>
>>>             <keepalive-time time="100" unit="milliseconds"/>
>>>         </unbounded-queue-thread-pool>
>> Rename this element to something like "batch-thread-pool".
> No problem. For some reason I was thinking we should allow different
> types to be used, but I guess it doesn't really matter. Really i that
> case it could just be defined within the "job-repository-type".

In fact the opposite is usually true.  The way the executor behaves 
often has a specific bearing on the performance, behavior, or 
reliability of the corresponding service.  For example a service which 
is expecting an unbounded or blocking executor might not actually have 
code to deal with rejection.  If the user unknowingly configures a 
bounded queue to such a service for whatever reason (typically because 
the user thinks that tweaking this knob will make it "better" somehow) 
then suddenly the service can fail in strange ways under load.

>>> </subsystem>
>>>
>>> This would make the model for the in-memory type something like;
>>> "subsystem" => {
>>>         "batch" => {
>>>             "job-repository" => "default",
>>>             "job-repository-type" => {"default" => {
>>>                 "type" => "in-memory",
>>>                 "thread-pool-name" => "default"
>>>             }}
>>>         }
>>> }
>>>
>>> The problem is I'm not sure what to do with JDBC which would also need a
>>> datasource/jndi-name attribute, but I don't want that attribute on the
>>> in-memory type.
>>>
>>> Another thought I had was to have it look more like;
>>> "subsystem" => {
>>>         "batch" => {
>>>             "job-repository" => "default",
>>>             "in-memory" => {"default" => {
>>>                 "thread-pool-name" => "default"
>>>             }},
>>>             "jdbc" => {"jdbc" => {
>>>                 "thread-pool-name" => "default",
>>>                 "jndi-name" => "java:jboss/datasources/ExampleDS"
>>>             }}
>>>         }
>>> }
>>>
>>> The problem here is really the jdbc resource could also be called
>>> default. I'm not sure if there is a way to query a parent resource to
>>> check each name, but if there is then maybe that's the way to go.
>>>
>>> Anyway, if anyone has suggestions let me know.
>> Why have a separate job-repository from job-repository-type?
>>
> The only reason was to not use a complex (OBJECT) value for the
> job-repository. In the ideal world I would just have something like
>
> "subsystem" => {
>       "batch" => {
>           "job-repository" => "in-memory" => {
>               "thread-pool" => {
>                   "max-threads" => 10,
>                   "keepalive" => {
>                       "time" => "100",
>                       "unit" => "milliseconds"
>                   }
>               }
>           }}
>       }
> }

Why would you have to use a complex object for the job repository?  Just 
make it a sub-resource.

> Of course for CLI that would be a huge PITA. Maybe it's the best
> solution though. I would simplify the XML as well to something more like;
> <subsystem xmlns="urn:jboss:domain:batch:1.0">
>       <job-repository>
>           <in-memory>
>               <thread-pool>
>                   <max-threads count="10"/>
>                   <keepalive-time time="100" unit="milliseconds"/>
>               </thread-pool>
>           </in-memory>
>       </job-repository>
> </subsystem>
>
> The question I would have for that is would it be acceptable to allow
> only specific values (in-memory and jdbc) for the job-repository key?

No.  If you have two possible "kinds" of things then they should be 
element types.  For example:

<in-memory-job-repository>
    <thread-pool>
        ...

or:

<jdbc-job-repository>
    <data-source name="java:..."/>
    <thread-pool>
        ...

There is some argument to be made to allow sharing thread pools between 
repositories; in this case it would be OK to move the thread pool to the 
top level.  Either way these things should all be sub-resources.

-- 
- DML