The only way to detect if a channel is closed (on either side) is to do
a read and see if there is an IO exception.
I've filed earlier:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=85 on a similar
problem.
(sorry to jump in late here)
John ROM wrote:
>Isn't the close difficutly everywhere in grizzly not just on reads
>
>for example in the moment even when application logic knows that
>client will closed connection there may be write records left in the async write queue
>which will then of course fails.
>
>
>
>
>
>-------- Original-Nachricht --------
>
>
>>Datum: Thu, 13 Nov 2008 16:43:21 +0100
>>Von: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
>>An: users_at_grizzly.dev.java.net
>>Betreff: Re: how to detect a client that close his connection to the server ?
>>
>>
>
>
>
>>>Jeanfrancois Arcand wrote:
>>>
>>>
>>>>Salut,
>>>>Jeanfrancois Arcand wrote:
>>>>
>>>>
>>>>>Salut,
>>>>>
>>>>>Oleksiy Stashok wrote:
>>>>>
>>>>>
>>>>>>Hi Sebastien,
>>>>>>
>>>>>>you can easily add custom Filter before ReadFilter.
>>>>>>Implement postExecute method, with approx. following code:
>>>>>>
>>>>>> public boolean postExecute(Context ctx) throws IOException {
>>>>>>
>>>>>> final Context.KeyRegistrationState state =
>>>>>>ctx.getKeyRegistrationState();
>>>>>>
>>>>>> if (state == Context.KeyRegistrationState.CANCEL){
>>>>>> notifyConnectionClosed();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>hum. Not sure it will works because one of the Filter can always
>>>>>set the KeyRegistrationState to CANCEL.
>>>>>
>>>>>
>>>>I need to avoid starting working too early ;-) Of course no Filter
>>>>will be invoked when the connection is closed :-)
>>>>Forget me!
>>>>
>>>>
>>>Naaa I think I was right at the first place :-) Your example will
>>>works but there is also chance that other filters set the value to
>>>cancel, and it will be hard from the Filter to detect if the client
>>>closed the connection or if the filter asked to close it.
>>>
>>>So I guess we need to add something :-) :-)
>>>
>>>
>>I think, in general it's very difficult to understand if client closed
>>connection or not. I would not rely on that...
>>To put some check in ReadFilter, when -1 is read, is not enough,
>>because connection could be closed inside protocol parser or any other
>>piece of code.
>>I think it's quite tricky scenario, when you really need to
>>distinguish situations, where client initialized connection close or
>>server.
>>
>>WBR,
>>Alexey.
>>
>>
>>
>>>A+
>>>
>>>-- Jeanfrancois
>>>
>>>
>>>
>>>
>>>
>>>>-- Jeanfrancois
>>>>I would propose we add a way to get
>>>>
>>>>
>>>>>notified when the client close the connection in ReadFilter
>>>>>(specially with ProtocolParser, because you can't override the
>>>>>ReadFilter.execute() method. What do you think?
>>>>>
>>>>>A+
>>>>>
>>>>>-- Jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hope this will help.
>>>>>>
>>>>>>WBR,
>>>>>>Alexey.
>>>>>>
>>>>>>
>>>>>>On Nov 13, 2008, at 4:08 , Survivant 00 wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>yes I'm using a ProtocolParser..
>>>>>>>
>>>>>>>QuoteQueryProtocolFilter protocolParser = new
>>>>>>>QuoteQueryProtocolFilter();
>>>>>>>
>>>>>>>:)
>>>>>>>
>>>>>>>I'll put a flag on my thread. I need to fix that before putting
>>>>>>>my application in test.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>2008/11/12 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com
>>>>>>>
>>>>>>>
>><mailto:Jeanfrancois.Arcand_at_sun.com
>>
>>
>>>>>>> Salut,
>>>>>>>
>>>>>>>
>>>>>>> Survivant 00 wrote:
>>>>>>>
>>>>>>> I just find a bug in my application. I don't know how to
>>>>>>>get
>>>>>>> notify when I client close the connection with the
>>>>>>>server. (TCP)
>>>>>>>
>>>>>>>
>>>>>>> I can't remember when we talked about that, but I was under the
>>>>>>> impression the ReadFilter has an API to register listener
>>>>>>>when the
>>>>>>> connection get closed. But looking at the code, I guess I've
>>>>>>> dreamed....
>>>>>>>
>>>>>>> The solution is to write your own SelectionKeyHandler and
>>>>>>>monitor
>>>>>>> the SelectionKey that are closed. But I don't really like the
>>>>>>> solution.
>>>>>>>
>>>>>>> The logic should really be in ReadFilter, but I suspect you are
>>>>>>> using ProtocolParser and let me investigate more...Alexey and
>>>>>>>John
>>>>>>> might wakes faster than me on that :-)
>>>>>>>
>>>>>>> A+
>>>>>>>
>>>>>>> -Jeanfrancois
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> here the init of the server
>>>>>>>
>>>>>>> public void init(){
>>>>>>> System.out.println("listening for incoming TCP
>>>>>>> Connections on port : " + f_port);
>>>>>>> try {
>>>>>>> f_controller = new Controller();
>>>>>>> TCPSelectorHandler tcpSelectorHandler = new
>>>>>>> TCPSelectorHandler();
>>>>>>> tcpSelectorHandler.setPort(f_port);
>>>>>>>
>>>>>>> Pipeline pipeline = new DefaultPipeline();
>>>>>>> pipeline.setMaxThreads(5);
>>>>>>> f_controller.setPipeline(pipeline);
>>>>>>>
>>>>>>>tcpSelectorHandler.setSelectionKeyHandler(new
>>>>>>> BaseSelectionKeyHandler());
>>>>>>>
>>>>>>>f_controller.addSelectorHandler(tcpSelectorHandler);
>>>>>>> QuoteQueryProtocolFilter
>>>>>>>protocolParser =
>>>>>>> new QuoteQueryProtocolFilter();
>>>>>>> QuoteQueryManagerFilter quoteManagerFilter = new
>>>>>>> QuoteQueryManagerFilter(f_quoteManager);
>>>>>>> final ProtocolChain protocolChain = new
>>>>>>> DefaultProtocolChain();
>>>>>>> protocolChain.addFilter(protocolParser);
>>>>>>> protocolChain.addFilter(quoteManagerFilter);
>>>>>>> ((DefaultProtocolChain)
>>>>>>> protocolChain).setContinuousExecution(true);
>>>>>>>
>>>>>>>
>>>>>>> ProtocolChainInstanceHandler pciHandler = new
>>>>>>> DefaultProtocolChainInstanceHandler() {
>>>>>>>
>>>>>>> public ProtocolChain poll() {
>>>>>>>
>>>>>>> return protocolChain;
>>>>>>> }
>>>>>>>
>>>>>>> public boolean offer(ProtocolChain
>>>>>>>protocolChain) {
>>>>>>> return false;
>>>>>>>
>>>>>>> }
>>>>>>> };
>>>>>>>
>>>>>>>
>>>>>>>f_controller.setProtocolChainInstanceHandler(pciHandler);
>>>>>>> try {
>>>>>>> f_controller.start();
>>>>>>> } catch (IOException e) {
>>>>>>> e.printStackTrace();
>>>>>>> }
>>>>>>> } catch (Exception e) {
>>>>>>> System.exit(-10);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>---------------------------------------------------------------------
>>
>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>>> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
>>>>>>> For additional commands, e-mail: users-
>>>>>>>help_at_grizzly.dev.java.net
>>>>>>> <mailto: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
>>>
>>>