On Nov 13, 2008, at 17:23 , Jeanfrancois Arcand wrote:
>
>
> Oleksiy Stashok wrote:
>>> Oleksiy Stashok wrote:
>>>> 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.
>>>
>>> I would think we need to unify the process, don't you think? Just
>>> the fact that you need to add a special filter is not good IMO. My
>>> proposal might not work as well, but let's brainstorm on a generic
>>> way that cover all cases.
>> We can add some hook to the SelectionKeyHandler.cancel(), but it
>> will not distinguish between connections closed by client or server.
>
> Then this is not the right place :-)
>
>
>> And again I'm not sure about scenario, why we need this? I mean
>> process separately connections, which we assume were closed by
>> client or server?
>
> If a connection get closed by the client, you might want to free
> resource associated with it. Right now it is complicated to
> implement IMO. You might not want to the same when the connection
> times out etc. Two persons (Sebastien and Amy...and Harsha a while
> ago) asked the features :-) I think there is a need...
But if connection is closed by server the same resources should be
released either. What is the difference?
WBR,
Alexey.
>
>
> A+
>
> --Jeanfrancois
>
>
>
>> Thanks.
>> WBR,
>> Alexey.
>>>
>>>
>>> A+
>>>
>>> - Jeanfrancois
>>>
>>>
>>>
>>>> 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
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>