[wildfly-dev] Batch Subsystem Model
Brian Stansberry
brian.stansberry at redhat.com
Fri Sep 13 09:02:09 EDT 2013
On 9/13/13 12: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.
Make it simply "thread-pool". EJB is the outlier here; generally model
references are just interface="public", socket-binding="http" etc.
>>>>> <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.
You register separate ResourceDefinitions for the two legal types, with
the PathElement param passed into the SimpleResourceDefinition c'tor
being the two param key/value variant instead of the one param key only
variant.
Enforcing that only one is present is done in the parser and by having
the add step handler for each of those add a Stage.MODEL step that
validates the model for this constraint. The validation step will
execute after any regular Stage.MODEL steps in the same batch, so it
will see the model state after all the user-defined actions have been
created. For example, with a composite op that adds
job-repository=in-memory and removes job-repository=jdbc, the validation
step will execute after the add and the remove.
>>
>>> 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.
>>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list