Simon Trudeau wrote:
> No problem... but what is an RFE? :.) Provide me with the URL and I will
> do it.
>
> Simon
>
> -----Original Message-----
> From: Jeanfrancois.Arcand_at_Sun.COM [mailto:Jeanfrancois.Arcand_at_Sun.COM]
> Sent: March-06-08 2:02 PM
> To: users_at_grizzly.dev.java.net
> Subject: Re: [Q] Trouble invoking the selectorHandler protocolChain
>
>
>
> Simon Trudeau wrote:
>
>> Euhm... well, that explains it. I would have expected the framework to
>> be a bit more symetrical in its execution of filter chain between
>> clients and servers...
>>
>
> More and more people are also saying that....Time for filling and RFE
>
There is ONE already ..
[Issue 41] New - Remove the asymmetry in channel event handling in Grizzly
thanks,
Harsha
> :-)
>
>
>> So, if I recap:
>>
>> Scenario 1:
>> - Client sends packet to server
>> - server selectorHandler's protocolChain gets invoked then,
>> - server controller's protocolChain gets invoked.
>>
>> Scenario 2;
>> - Client receive packets from server
>> - Client connectorHandler's callbackHandler onConnect() and onRead()
>> method get invoked then... ??? Nothing or does the client controller's
>> protocolChain gets invoked?
>>
>> Like you have explained, the connectorHandler associated
>> selectorHandler's protocolChain doesn't get called.
>>
>> Do I understand everything correctly?
>>
>
> Yes.
>
>
>
>> Until now, I had always assumed that all filterChains were kind of
>> connected but acting at a different level of granularity.
>>
>> - The CallBackHandler would act at the individual connection level
>> - The selectorHandler's filterChain would act on all connection
>>
> incoming
>
>> to a port or from a protocol.
>> - And the Controller'S filterChain would act on all connections.
>>
>
> That's interesting (I like the idea)...right now only your first two
> bullet are supported. The Controller filter chain will acts on all
> incoming connection to SelectorHandler, but like you have found, not on
> ConnectorHandler.
>
> I will think how we can support that by default....Do you mind (sorry
> for asking) filling an RFE with your observation? That way we will not
> forget it!
>
> Thanks!
>
> -- Jeanfrancois
>
>
>
>> How should I be looking at this?
>>
>> Thanks,
>>
>>
>> Simon
>>
>> Simon Trudeau wrote:
>>
>>> Here's my trouble I am almost done building this very nifty client
>>> (attached to this email) following our previous thread of discussion
>>> (thanks alot!) but my only trouble is that my protocolChain from my
>>> selectorHandler never gets invoked! I really don't understand what
>>>
>> needs
>>
>>> to be done to invoke it, I though it would get invoked automatically
>>> when a packet is read on the channel.
>>>
>> Inside you ClientCallBackHandler onRead/OnWrite, make sure you call:
>>
>> ctx.getProtocolChain().execute(ioEvent.attachment());
>>
>> because by default, the framework doesn't invoke the protocol chain
>>
> for
>
>> the client.
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>>>
>>>
>>> On the server side, the protocolChain from the Controller gets
>>>
> invoked
>
>>> without a glitch. I know that because my server implements and
>>> EchoFilter and the callbackHandler from my client receives something
>>>
>> (it
>>
>>> triggers on OnRead()).
>>>
>>>
>>>
>>> I could really appreciate some pointers! 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>