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
> injection.
>
Right. The real issue however is whether a "module" should be able to
"configure" its own thread-pool. By making thread-pool a shared resource,
we are saying that its configuration is going to (possibly) affect all the
modules that share it. Something like the configuration of the JVM itself.
If thread-pool is akin to the JVM (specified as java-config element in
domain.xml) then what you suggest is something we should do, not otherwise. In
the case we decide to make it a shared resource, should it be a part of
java-config or something similar (to identify it as shared resource)?
-Kedar
> Ken.