Hi,
Harsha Godugu wrote:
> Hi Jeanfrancois,
>
> How does Grizzly v1.6.0 handle the following scenario:
> The underlying channel gets closed (unexpectedly, due to say some
> network problem.. or loose contact etc.. and then backs up to live )
> while reading data using ReadFilter. Consider this can happen on both
> client and server side.
>
> I see that, the ReadFilter class sets an attribute in Context, in case
> of an exception. But that same attribute is removed in the
> postExecute(..) method of ReadFilter.
Right, but just before we tell the SelectorHandler to cancel/close the
SelectionKey.
How does user of Grizzly know, if
> there is an IO exception (ChannelClosedException..) while reading data
> using the filter? Do we have state listeners of connection to monitor
> connection state? (Similar to Controller state!)
With the default ReadFilter, the user doesn't have the control as the
ProtocolChain execution will be interrupted, meaning the next Filter
will never get invoked. Why would you like to continue the execution
when you know the connection is closed? We can make the behavior
configurable if you have a scenario when ProtocolFilter needs to be
invoked with a 'close' connection.
Thanks
-- Jeanfrancois
>
> Thanks,
> Harsha
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>