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.
Ken.