[wildfly-dev] Batch Subsystem Model

[James R. Perkins]

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.
>

-- 
James R. Perkins
Red Hat JBoss Middleware