[jboss-as7-dev] Two thread pools sections in management API

[Brian Stansberry]

HornetQ has a similar situation. Looking at the internals, it seemed HQ 
was using a pretty generic thread pool, so if there was a hook so the AS 
could inject one we could use the AS standard configs in the messaging 
subsystem.

On 10/20/11 11:15 AM, Andrig Miller wrote:
> One thing that I have found with playing around with the various
> subsystems, is JBoss Web. JBoss Web doesn't expose a thread pool
> configuration, just a single attribute called max-connections. It also
> then has an "executor" attribute, which just takes a thread pool name
> from the JBoss Threads configuration.
>
> So, this one is inconsistent with the other subsystems, and I'm not sure
> if it should be changed to be consistent or not, since the default
> doesn't use JBoss Threads. This would also complicate any "global" view
> in the console.
>
> Andy
>
> ------------------------------------------------------------------------
>
>     *From: *"David M. Lloyd" <david.lloyd at redhat.com>
>     *To: *jboss-as7-dev at lists.jboss.org
>     *Sent: *Thursday, October 20, 2011 9:18:12 AM
>     *Subject: *Re: [jboss-as7-dev] Two thread pools sections in
>     management API
>
>     The name issue wouldn't be quite so bad if we introduced some contract
>     for each subsystem to introduce a unique name for their pools, and
>     maybe
>     another optional level of naming if they have more than one pool
>     "namespace" in a subsystem. Then a centralized view could be pretty
>     intuitive: "Thread Pools -> EJB -> ..."
>
>     On 10/20/2011 10:12 AM, Brian Stansberry wrote:
>      > I struggled with that global view a bit over the last week.
>      >
>      > I was thinking about approaching it as having it be a set of
>     resources
>      > in the threads subsystem that are basically just views onto the real
>      > resource, which would exist in JCA, EJB etc.
>      >
>      > That's not very satisfying. Leads to things like having to avoid
>      > conflicts in pool names across subsystems. Plus it would be
>     pretty hard
>      > to implement.
>      >
>      > I was noodling a bit this morning about separating the UI issue
>     from the
>      > core model a bit. The core model (in the threads subsystem) could
>     just
>      > provide resources addresses (and maybe a bit more metadata) about
>     pools
>      > configured elsewhere. The resources for pools would be consistent
>      > throughout the model (e.g. a bounded-queue-thread-pool that supports
>      > blocking would have the same attributes, ops, etc everywhere). The
>      > console could use the info from the threads subsystem to discover all
>      > the pool configs and then build a nice UI.
>      >
>      > I suspect that's a problem for JON though. The CLI of course
>     wouldn't be
>      > able to produce a nice unified view, but IMHO that's not a
>     critical problem.
>      >
>      > On 10/20/11 8:16 AM, Jason Greene wrote:
>      >> Right. What happened is we found out that having thread pools be
>     global
>      >> promotes sharing, which is usually an error since each subsystem
>     needs
>      >> specific configurations. We were planning on adding a global
>     view that
>      >> would see all the subsystems' thread pools so the administrator can
>      >> easily identify which were in use however I don't think it was
>     completed
>      >> yet. Even though we neat them in the subsystem we still want
>     them to be
>      >> consistent.
>      >>
>      >> Sent from my iPhone
>      >>
>      >> On Oct 20, 2011, at 5:58 AM, Heiko Braun<hbraun at redhat.com
>      >> <mailto:hbraun at redhat.com>> wrote:
>      >>
>      >>>
>      >>>
>      >>> no, but if possible they should rely on the default schema
>     (xsd) for
>      >>> defining inlined thread pool configurations.
>      >>>
>      >>> On Oct 20, 2011, at 12:50 PM, David Bosschaert wrote:
>      >>>
>      >>>> It seems that the latter defines pools that are used in
>      >>>> /subsystem=ejb3/service=*
>      >>>> Should they not be using thread pools defined in the threads
>     subsystem
>      >>>> instead?
>      >>>
>      >>> _______________________________________________
>      >>> jboss-as7-dev mailing list
>      >>> jboss-as7-dev at lists.jboss.org<mailto:jboss-as7-dev at lists.jboss.org>
>      >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >>
>      >>
>      >> _______________________________________________
>      >> jboss-as7-dev mailing list
>      >> jboss-as7-dev at lists.jboss.org
>      >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >
>      >
>
>
>     --
>     - DML
>     _______________________________________________
>     jboss-as7-dev mailing list
>     jboss-as7-dev at lists.jboss.org
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat