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 <mailto: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
>> <mailto:oleksiy.stashok_at_oracle.com>>
>> Reply-To: <dev_at_grizzly.java.net <mailto:dev_at_grizzly.java.net>>
>> Date: Thu, 29 Mar 2012 11:59:16 +0200
>> To: <dev_at_grizzly.java.net <mailto: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
>>
>
>