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

[Andrig Miller]

Yep, I forgot about that one. In fact, I think the default configuration is to just create threads as needed, and then the go away. If you specify the thread pool parameter than it will pool and keep them around. 

Andy 

----- Original Message -----

> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: jboss-as7-dev at lists.jboss.org
> Sent: Thursday, October 20, 2011 11:02:25 AM
> Subject: Re: [jboss-as7-dev] Two thread pools sections in management
> API

> 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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20111020/70caa837/attachment.html