Simon Trudeau wrote:
> 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! :.)
LOL. This is the right approach :-) An alternative is to do:
TCPSelectorHandler.acquireConnectorHandler() will return a
ConnectorHandler that is already configured to use the TCPSelectorHandler.
A+
-- Jeanfrancois
>
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>