Thanks for the info, its getting clearer and clearer!
I was about to post another question but suddenly after looking at the
api, I'm pretty sure I found my answer, I'm posting it anyway to it
might help others.
*****
What I still don't know is how to bind a selectorHandler to a
connectorHandler.
For example:
Lets say I have clients cA, cB, cC of type T1.
cA communicates with server sA,
cB with sB and
cC with sC.
I also have clients cD, cE, cF ot type T2.
cD communicates with server sD,
cE with sE and
cF with sF.
In my client application I would create a TCPSelectorHandler
(myT1SelectorHandler) to handle all incoming server communication from
server sA, sB and sC.
I would also create another TCPSelectorHandler (myT2SelectorHandler) to
handle all incoming server communication from server sE, sE and sF.
My trouble is the following:
Both my selectorHandler are of type TCPSelectorHandler and I don't
really know or care about the port on which they will listen to.
Currently I have one connectorHandler per client (cA... cF) but I don't
have any control on which of my two selectorHandler will get invoked by
my myConnectorHandler.connect(sA...) call.
How can I make sure that a call to myConnectorHandler.connect(sA...)
will bind to myT1SelectorHandler and not to myT2SelectoryHandler?
When invoking the myConnectorHandler.connect() method, I don't want to
specify a local port on which to listen to using when...
Doh! I have found my answer, I will still post this message so other
users with the same trouble can have an answer.
The answer is, and correct me if I'm wrong:
ConnectorHandler.java
...
public void connect(SocketAddress remoteAddress,
CallbackHandler callbackHandler,
TCPSelectorHandler selectorHandler)
...
I assume that this method allows to assign a selectorHandler to a
connectorHandler. This way I can assign myT1SelectorHandler to cA and
myT2SelectorHandler to cD.
Lets hope all my questioning will help others than me! :.)
Simon
-----Original Message-----
From: Jeanfrancois.Arcand_at_Sun.COM [mailto:Jeanfrancois.Arcand_at_Sun.COM]
Sent: March-04-08 12:55 PM
To: users_at_grizzly.dev.java.net
Subject: Re: [Q] SelectorHandler and ConnectorHandler relationship
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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: users-help_at_grizzly.dev.java.net