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 :-)
Where is your patch, Mr. Hunt :-)
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