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.
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 :-)
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