On Wed, 2008-08-13 at 21:29, Ken Cavanaugh wrote:
> Kedar Mhaswade wrote:
> >
> >
> > Jan.Luehe_at_Sun.COM wrote:
> >> Kedar Mhaswade wrote:
> >>
> >>>
> >>>
> >>> Ken Cavanaugh wrote:
> >>>
> >>>> Kedar Mhaswade wrote:
> >>>>
> >>>>> I see the following snippet in domain.xml:
> >>>>>
> >>>>> <thread-pools> <thread-pool
> >>>>> thread-pool-id="thread-pool-1" min-thread-pool-size="0"
> >>>>> max-thread-pool-size="200" i
> >>>>> dle-thread-timeout-in-seconds="120" num-work-queues="1"/>
> >>>>> </thread-pools>
> >>>>>
> >>>>> Is anything in v3 runtime using this snippet?
> >>>>>
> >>>>> I am planning on removing this from Prelude's web-bundle default
> >>>>> domain.xml.
> >>>>
> >>
> >>
> >> Just to confirm: This will be restored post prelude, right?
> >> (If so, why remove it now and restore it later?)
> >>
> >> The new Grizzly <network-config> is going to deprecate the use of
> >> <connection-pool> in favor of <thread-pool>, so we'll definitely require
> >> this element post prelude.
> >
> > OK. Thanks for letting me know. I am almost certain that even if we use
> > it then, we will have to change the way it looks, isn't it?
> >
> > Anyway, I will not remove it from domain.xml.
> >
> > From the common use standpoint, if multiple modules are going to use it,
> > this probably is going to be a shared config, right?
> >
> > What are the reasons to have a shared thread-pool for the modular server?
> >
> Whether the server is modular or not, it is essential that we can manage
> shared
> resources effectively. Exactly what the thread pool will look like is
> something that
> needs more study, but requirements like request prioritization and some
> other
> work will cause us to refine what the threadpool API looks like. We will
> quite likely move to something like the ThreadPoolExecutorService API,
> which seems to support most of the requirements.
>
> What we probably want to do here is turn the thread pool
> into a shared service in the nucleus that anyone can get to using dependency
Note that our experience from the grizzly threadpool is that the
complexity of the executor service can lead to performance degredations,
particularly for lots of short requests handled by a few threads. On the
other hand, the separation between http and ORB thread pools has been
very important for us. So if we go this route, the challenge will be to
introduce request prioritization or whatever and not degrade the
performance.
-Scott
> injection.
>
> Ken.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>