Simon Trudeau wrote:
> I would like to clarify something with you about SelectorHandler and
> ConnectorHandler (still working on my client side application… :.) ):
>
>
>
> My understanding is that there is a one to many relationship between the
> SelectorHandler and the ConnectorHandler (one SelectorHandler and many
> ConnectorHandler).
>
So far so good :-)
>
>
> - Given that my application wants to create two types of clients and
> many instances of those two types (types of clients differ by their
> protocol and business logic handling of responses to requests), I assume
> that clients will have unique ConnectorHandler but all clients will
> share the same TCPSelectorHandler.
It is a design decision. You might create two SelectorHandler (with
different port) so you can have one SelectorHandler per set of
ConnectorHandler. Or like you said, one SelectorHandler for two set of
ConnectorHandler.
>
> - If I am right, it means that I can only instanciate one type of
> protocol chain and associate it with the TCPSelectorHandler.
Right. You can probably customize the Controller, but I would not like
>
> - So it means that I cannot handle both protocols for the two types of
> clients using the SelectorHandler.
You really needs to set of ProtocolChain? Why not adding an
attribute...basic question, how do you know which remote server you are
connected to?
>
> - Does that mean my only options to handle protocol specific actions is
> to make use of the CallBackHandler associated with the different
> connections?
I would put that logic inside a ProtocolFilter instead of the
CallbackHandler.
>
>
>
> Sorry about all my complicated settings, don’t think I’m one of those
> annoying users…
No you are not at all :-) You documentation is not good and questions
like that help us to clean it.
Basically, my goal is to limit thread creation and
> resource consumption. The client application I am working on is bound to
> grow and will poll information from many different services provided by
> legacy devices (aka server). I will end up having lots of clients of
> many different types. I don’t want to exhaust my resources creating
> clients! Looking at Grizzly, I thought I could share a Grizzly
> Controller among all my clients, thus all clients could share the same
> pool of resources or clients make use of a specific pool given their
> types or priority…
Agree. But I suspect you might use one Controller with 2 or more
SelectorHandler.
>
>
>
> Could I have one controller per client types, but share the thread pool
> among all controller (client types) I guess all my mombo jumbo above
> could be easily addressed. Looking at the API, I see there is the
> Controller.setPipeline() method… Maybe I could use that and share a
> common pipeline for all clients of a given type? What do you think?
> Would there be other pipeline which I would need to share?
Let say you go with 1 Controller and X SelectorHandler. You can
configure Pipeline at the SelectorHandler level, or at the COntroller
level. In your case, I would think two Pipeline at the SelectorHandler
level would works. What do you think>
>
>
>
> I would appreciate background information on Grizzly threading model
> (could be a nice tutorial!)
Hahaha...you can also write one :-) In short, the Pipeline can be any
kind of thread pool...just need to implement the Pipeline interface (so
you can inject your own). You can share a thread pool among
SelectorHandler by setting it at the Controller level, or set one
Pipeline per SelectorHandler.
Does it help?
Keep the questions :-)
-- Jeanfrancois
>
>
>
> Thanks,
>
>
>
>
>
> Simon
>
>
>