From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Thu, 19 Jun 2008 12:35:08 -0400

Salut,

Oleksiy Stashok wrote:
> Hi,
>
> On Jun 19, 2008, at 2:32 , Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> Ken Cavanaugh wrote:
>>> Jeanfrancois Arcand wrote:
>>>> Salut,
>>>>
>>>> the second issue we had is the concept of Controller. Alexey
>>>> proposed we get rid of this central notion and instead manipulate
>>>> Transport object, with no relationship between them. I do think
>>>> having a central object (Controller) to be able to set things like
>>>> thread pool and SelectorHandler is a good idea and makes users
>>>> experience simple.
>>>>
>>>> On that one, I'm +0 :-) but let discuss the pros and cons.
>>>>
>>> I think we need a central object for resource management.
>>> I proposed calling this simply TransportManager. I think it needs to:
>>> 1. Manage thread pool(s) (and this needs to be pluggable to handle
>>> things like Sahoo's scheme for request prioritization).
>>> 2. Manage ByteBuffer pools (like the scheme I proposed, in which the
>>> SlabPool would naturally be found in the TransportManager).
>>> 3. Act as a factory for transports.
>>> What other centralized responsibilities should this class have?
>>
>> The Controller right now can also handle the SelectionKeyHandler (one
>> per transport, or shared), the ProtocolChainInstanceHandler (to decide
>> if ProtocolChain are stateless or stateful), and many more.
> Theoretically yes, but this is deprecated right now. We don't recommend
> to share neither SelectorHandler nor SelectionKeyHandler even for 1.7+.
>
>
>> With Alexey's proposal, we will have to explicitly set those to each
>> transport implementation if we want to share component. With the
>> current Controller, I suspect this is simpler/less code to manage.
>> Also, is the Controller name that confusing so we want to rename it
>> TransportManager? I guess yes :-)
> During the meeting I agree, that we need to have something like
> Controller to share what is possible to share among different transports.
> Though I think this class should be optional to use - just in case of
> several transports. So if developer doesn't have several transports - he
> can avoid using Controller/TransportManager.

+1 for optional.


> IMHO, it's possible to share: MemoryManager, ThreadPool,
> EventProcessorSelector?, ProtocolChain (for same transport type)?

I would say yes :-)

Thanks

-- Jeanfrancois


>
> Thanks.
>
> WBR,
> Alexey.
>
>>
>>
>> A+
>>
>> --Jeanfrancois
>>
>>
>>> Thanks,
>>> Ken.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net For
>>> additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>