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...
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
>