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.

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

> </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?

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.

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.

Thanks for all the feedback. If I'm understanding everything right we'll end with something like the following for in-memory. <subsystem xmlns="urn:jboss:domain:batch:1.0"> <job-repository> <in-memory thread-pool="default"/> </job-repository> <thread-pool name="default"> <max-threads count="10"/> <keepalive-time time="100" unit="milliseconds"/> </thread-pool> </subsystem> "subsystem" => { "batch" => { "job-repository" => { "in-memory" => { "thread-pool" => "default" }}, "thread-pool" => { "default" => { "max-threads" => "10", "keepalive-time" => "100", "keepalive-unit" => "milliseconds" }} } } And something like the following for JDBC. <subsystem xmlns="urn:jboss:domain:batch:1.0"> <job-repository> <jdbc thread-pool="default" jndi-name="java:jboss/datasources/ExampleDS"/> </job-repository> <thread-pool name="default"> <max-threads count="10"/> <keepalive-time time="100" unit="milliseconds"/> </thread-pool> </subsystem> "subsystem" => { "batch" => { "job-repository" => { "jdbc" => { "thread-pool" => "default", "jndi-name" => "java:jboss/datasources/ExampleDS" }}, "thread-pool" => { "default" => { "max-threads" => "10", "keepalive-time" => "100", "keepalive-unit" => "milliseconds" }} } } I personally prefer the <job-repository><in-memory/></job-repository> over the <in-memory-job-repository/>, but I don't care all that much. If the consensus is the later, that's fine.

Also do we want the thread pool to be called batch-thread-pool or just simply thread-pool?

Thanks for all the feedback. I just wanted to get it right since what we decide we're stuck with.

On 9/13/13 11:17 AM, James R. Perkins wrote: > Thanks for all the feedback. If I'm understanding everything right we'll > end with something like the following for in-memory. > > <subsystem xmlns="urn:jboss:domain:batch:1.0"> > <job-repository> > <in-memory thread-pool="default"/> > </job-repository> > <thread-pool name="default"> > <max-threads count="10"/> > <keepalive-time time="100" unit="milliseconds"/> > </thread-pool> > </subsystem> Why does a job repository need to reference a thread-pool as its attribute? thread-pool is for job execution and not tied to how jobs are kept in job repository. By having a top-level <thread-pool>, it tells this thread-pool configuration is to be used by batch runtime, regardless in-memory or jdbc job repository. In your current design, it seems users can configure multiple <thread-pool> elements and choose one to use. But I don't see this is really necessary, and still a job repository need not be associated with a thread-pool.

Cheng > "subsystem" => { > "batch" => { > "job-repository" => { "in-memory" => { > "thread-pool" => "default" > }}, > "thread-pool" => { "default" => { > "max-threads" => "10", > "keepalive-time" => "100", > "keepalive-unit" => "milliseconds" > }} > } > } > > And something like the following for JDBC. > > <subsystem xmlns="urn:jboss:domain:batch:1.0"> > <job-repository> > <jdbc thread-pool="default" > jndi-name="java:jboss/datasources/ExampleDS"/> > </job-repository> > <thread-pool name="default"> > <max-threads count="10"/> > <keepalive-time time="100" unit="milliseconds"/> > </thread-pool> > </subsystem> > > "subsystem" => { > "batch" => { > "job-repository" => { "jdbc" => { > "thread-pool" => "default", > "jndi-name" => "java:jboss/datasources/ExampleDS" > }}, > "thread-pool" => { "default" => { > "max-threads" => "10", > "keepalive-time" => "100", > "keepalive-unit" => "milliseconds" > }} > } > } > > I personally prefer the <job-repository><in-memory/></job-repository> > over the <in-memory-job-repository/>, but I don't care all that much. If > the consensus is the later, that's fine. > > Also do we want the thread pool to be called batch-thread-pool or just > simply thread-pool? > > Thanks for all the feedback. I just wanted to get it right since what we > decide we're stuck with. > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev