11:02 p.m.
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".
> </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"
}
}
}}
}
}
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?
--
James R. Perkins
Red Hat JBoss Middleware