From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Thu, 14 Feb 2008 17:23:07 -0500

charlie hunt wrote:
> Jeanfrancois Arcand wrote:
>> charlie hunt wrote:
>>> I've (finally) started working one of my very, very old action items
>>> to integrate a Grizzly transport into one of our Java SE performance
>>> benchmarks.
>>>
>>> In doing so I ran across something I think we might consider changing
>>> with Grizzly's Controller. I would like to hear other's comments.
>>>
>>> Should we consider refactoring the initialization logic of
>>> Controller's default Pipeline, default ProtocolChainInstanceHandler
>>> and default SelectorHandler into a private method called
>>> initializeDefaults() ?
>>>
>>> Here's why I'm suggesting this ....
>>>
>>> Suppose you want to use the default Pipeline,
>>> ProtocolChainInstanceHandler and SelectorHandler. But, you want to
>>> change the max threads on the default Pipeline. So, you write some
>>> code that looks like:
>>>
>>> // create a Grizzly Controller
>>> Controller controller = new Controller();
>>>
>>> // add a TCPSelectorHandler
>>> TCPSelectorHandler selectorHandler = new TCPSelectorHandler();
>>> selectorHandler.setPort(port);
>>> controller.addSelectorHandler(selectorHandler);
>>>
>>> // add a ProtocolChainInstanceHandler & ProtocolChain
>>> ProtocolChainInstanceHandler pciHandler =
>>> new ProtocolChainInstanceHandler() {
>>> final private ProtocolChain protocolChain =
>>> new DefaultProtocolChain();
>>> public ProtocolChain poll() {
>>> return protocolChain;
>>> }
>>> public boolean offer(ProtocolChain pc) {
>>> return true;
>>> }
>>> };
>>> controller.setProtocolChainInstanceHandler(pciHandler);
>>>
>>> // add my two favorite ProtocolFilters
>>> pciHandler.poll().addFilter(new ReadFilter());
>>> pciHandler.poll().addFilter(new EchoFilter());
>>>
>>> // Explicit set the number of threads in the Pipeline
>>> controller.getPipeline().setMaxThreads(5); <---
>>> NullPointerException
>>
>> Oups :-)
>>
>>>
>>> The problem here is that the default Pipeline is not instantiated
>>> until Controller.start() is called. Alternatively, I could have done
>>> controller.setPipeline(new DefaultPipeline().setMaxThreads(5)); to
>>> avoid the NullPointerException.
>>>
>>> I'm proposing that the Controller constructor initialize the default
>>> Pipeline, default SelectorHandler and default
>>> ProtocolChainInstanceHandler. I further propose that the
>>> initializing of the default Pipeline, SelectorHandler and
>>> ProtocolChainInstanceHandler be encapsulated in a private (or
>>> possibly a protected) method called initializeDefaults().
>>
>> I like the idea, but we need to make sure we only initialize the
>> objects above, but we don't start them. Why? Because if your
>> application is UDP based, you don't want to initialize and start a
>> TCPSelectorHandler :-)
>
> In complete agreement.
>
>>
>> Where is your patch, Mr. Hunt :-)
>
> :-P
>
> Not gonna do a patch unless I hear agreement on the idea.

You have my +1 :-)

>
> charlie ...
>
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>>
>>> Your thoughts?
>>>
>>> charlie ...
>>>
>>> ---------------------------------------------------------------------
>>> 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