[wildfly-dev] Batch Subsystem Model

[Cheng Fang]

On 9/13/13 1:13 AM, James R. Perkins wrote:
> On 09/12/2013 09:10 PM, David M. Lloyd wrote:
>> 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.
> That actually makes sense and it's how EJB is setup.
>>>>> </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.
> I guess I meant sub-resource, but I wasn't sure if you could limit
> sub-resources. Like only allow specific names like
> job-repository=in-memory OR job-repository=jdbc. Essentially I need to
> have one or the other, but not both and no other values should be allowed.
>>> 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.
> In this specific case it might not matter because you can only define
> one job repository type.

executor-service or thread-pool is independent of job repository type.  
I think it's more natural to have thread-pool or any concurrency-related 
elements as top-level elements.

Cheng