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.
But I need someplace to create an instance of a transport. Why not do
this in the
TransportManager? Something like:
TransportManager.makeXXXTransport( ... )
or
TransportManager.instance().makeXXXTransport( ... )
I'd rather avoid explicit calls to new to create a transport:
new always requires creating a new instance, whereas factory
methods can be more flexible.
Thanks,
Ken.