I have filled up ticket #89 for this issue. I would have liked to update
the ticket #41 but it seems that I don't have permission to update a
ticket (maybe I would need to join the development mailing list or
something...). Anyway, now the issue won't get lost!
Simon
________________________________
From: Harsha.Godugu_at_Sun.COM [mailto:Harsha.Godugu_at_Sun.COM]
Sent: March-06-08 2:26 PM
To: users_at_grizzly.dev.java.net
Subject: Re: [Q] Trouble invoking the selectorHandler protocolChain
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