>>> 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...
>
> Hum...Since we disable OP_READ, the upstream Filter will need to
> execute a read and get the exception/-1. But if they don't, then the
> ReadFilter will eventually handle the case
yes.
If upstream filter got exception/-1 - Then it should notify Grizzly
about closed connection, because otherwise Grizzly will never get
notification.
>> To put some check in ReadFilter, when -1 is read, is not enough,
>
> Note that on win32/IE, you never get -1 but instead the read/write
> operation throws an IOException (how nice ;-))
Right :)
> because
>> connection could be closed inside protocol parser or any other
>> piece of code.
>
> But the next time OP_READ happens, the -1 will pops up in ReadFilter.
Only in case, if OP_READ is registered. But if exception happened
somewhere inside upstream filter - ReadFilter with -1 will never be
executed for the connection.
>> I think it's quite tricky scenario, when you really need to
>> distinguish situations, where client initialized connection close
>> or server.
>
> At least I would like to propose we add a
> Context.KeyRegistrationState.CLIENT_CLOSED event that can be used to
> detect basic scenario.
> What do you think?
I really think this could not be implemented reliably.
What is scenario for this? Why we should distinguish who closed
connection? When I unplug network cable on server, does it mean client
closed connection or server? :)
Thanks.
WBR,
Alexey.
>
>
> A+
> -- Jeanfrancois
>
>
>> 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
>>> 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
>