Oleksiy Stashok wrote:
>
> 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?
Might not, but might also :-) I think we should not restrict us. Aother
framework support such callback BTW :)
I"m looking at some possible solution right now
A+
-- Jeanfrancois
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>