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