I believe Async read/write queue have to be notified, when connection
is getting closed. It is implemented.
If it doesn't work - it's bug.
WBR,
Alexey.
> Salut
>
> 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.
>
> Right, and with OutputWriter, you will get the proper exception
> (IOException("Client disconnected");
>
> I think we are missing case for:
>
> + read
> + asyncRead/Write
>
> We may not be able to detect all scenario, but we can at least come
> with our best "guess".
>
> A+
>
> -- jeanfrancois
>
>
>> -------- 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>