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).
- 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.
- If I am right, it means that I can only instanciate one type of
protocol chain and associate it with the TCPSelectorHandler.
- So it means that I cannot handle both protocols for the two types of
clients using the SelectorHandler.
- Does that mean my only options to handle protocol specific actions is
to make use of the CallBackHandler associated with the different
connections?
Sorry about all my complicated settings, don't think I'm one of those
annoying users... 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...
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?
I would appreciate background information on Grizzly threading model
(could be a nice tutorial!)
Thanks,
Simon