Hi Alexey,
Thank you for fixing it.
It works fine! I will also apply the canceling logic for the invalid
connection to grizzly-memcached.
Thanks.
Regards,
Bongjae Chang
From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Reply-To: <dev_at_grizzly.java.net>
Date: Wed, 04 Apr 2012 16:55:21 +0200
To: <dev_at_grizzly.java.net>
Subject: Re: About connection leak
Hi Bongjae,
the issue has to be fixed on trunk and 2.2.x branch.
Once you received future - you can try to get Connection or cancel it.
Important thing to remember is when you call future.cancel(boolean) - check
the boolean result of this method. If it returned true - it means "connect"
operation has been canceled and Connection (if any was created) is going to
be closed. If future.cancel(boolean) returned false - it means result (or
failure) has already arrived and you can retrieve it using future.get().
Let me know if it works for you.
Thanks.
WBR,
Alexey.
On 03/29/2012 05:41 PM, Bongjae Chang wrote:
>
> Hi Alexey,
>
> Thank you for reviewing it.
>
> I will look forward to your fix!
>
>
>
> Thanks!
>
>
>
> Regards,
>
> Bongjae Chang
>
>
>
> On Fri, Mar 30, 2012 at 12:15 AM, Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
> wrote:
>
>>
>> Hi Bongjae,
>>
>> agree, with the current approach Future could be used just in passive mode,
>> but it's not possible to actively fire event via Future.
>> We'll fix it asap.
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>
>>
>>
>> On 03/29/2012 03:19 PM, Bongjae Chang wrote:
>>>
>>>
>>>
>>> Hi Alexey,
>>>
>>>
>>>
>>>
>>> When I considered the fix for implementing Future, it seemed to be so
>>> complicated(I think that maybe, some APIs should be changed).
>>>
>>>
>>>
>>>
>>> So I attached another solution for small changes of current sources.
>>>
>>>
>>>
>>>
>>> I think this issue has two cases.
>>>
>>> 1. timed out --> connection established --> user calls future.cancel()
>>> 2. timed out --> user calls future.cancel() --> connection established
>>>
>>> I think that the attached patch may resolve only case 2.
>>>
>>> About case 1, user should consider some logic for closing the leak
>>> connection .
>>>
>>>
>>>
>>>
>>>
>>> ---
>>>
>>> final Future<Connection> future = connectorHandler.connect(serverAddr);
>>>
>>> final Connection<SocketAddress> connection;
>>>
>>> try {
>>>
>>> connection = future.get(shortTimeout, timeunit);
>>>
>>> } catch( ...) {
>>>
>>> ...
>>>
>>> } catch(TimeoutException te) {
>>>
>>> future.cancel(true);
>>>
>>> // user should check the following.
>>>
>>> connection = future.getResult();
>>>
>>> if (connection != null) {
>>>
>>> connection.closeSilently();
>>>
>>> }
>>>
>>> }
>>>
>>> ---
>>>
>>>
>>>
>>>
>>>
>>> Maybe if we can implement new Future for connecting, user can call only
>>> future.cancel() without additional consideration.
>>>
>>>
>>>
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Bongjae Chang
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
>>> Reply-To: <dev_at_grizzly.java.net>
>>> Date: Thu, 29 Mar 2012 11:59:16 +0200
>>> To: <dev_at_grizzly.java.net>
>>> Subject: Re: About connection leak
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi Bonjae,
>>>
>>> you found a bug.
>>> IMO your expectation that future.cancel() has to close connection is
>>> correct, but we've never implemented it.
>>>
>>> Pls. file an issue (possible fix is also welcome :))
>>>
>>> Thank you.
>>>
>>> WBR,
>>> Alexey.
>>>
>>> On 03/29/2012 11:53 AM, Bongjae Chang wrote:
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>>
>>>> When I used grizzly-memcached, I experienced connection leak when the trial
>>>> of connecting a server was timed out.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Connecting logic is simple.
>>>>
>>>> ---
>>>>
>>>> final Future<Connection> future = connectorHandler.connect(serverAddr);
>>>>
>>>> final Connection<SocketAddress> connection;
>>>>
>>>> try {
>>>>
>>>> connection = future.get(shortTimeout, timeunit);
>>>>
>>>> } catch( ...) {
>>>>
>>>> ...
>>>>
>>>> } catch(TimeoutException te) {
>>>>
>>>> // at this point, connection is null and I don't need to get a
>>>> connection anymore. ---(1)
>>>>
>>>> }
>>>>
>>>> ---
>>>>
>>>>
>>>>
>>>>
>>>> When it was timed out at (1), the connection is null. So I couldn't
>>>> disconnect the connection.
>>>>
>>>> At (1), the only way which I could try to do was "future.cancel()" but the
>>>> connection was not disconnected. If the connection will be established
>>>> successfully after timeout, the connection will be alive forever.
>>>>
>>>>
>>>>
>>>>
>>>> I would like to know how to disconnect the late connection after timeout in
>>>> order to prevent the connection leak.
>>>>
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Bongjae Chang
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>