Return-Path: X-Original-To: apmail-hc-dev-archive@www.apache.org Delivered-To: apmail-hc-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1CBD8E2F5 for ; Tue, 5 Feb 2013 10:57:30 +0000 (UTC) Received: (qmail 31651 invoked by uid 500); 5 Feb 2013 10:57:29 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 31428 invoked by uid 500); 5 Feb 2013 10:57:28 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 31386 invoked by uid 99); 5 Feb 2013 10:57:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 10:57:26 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of asankha.apache@gmail.com designates 209.85.220.54 as permitted sender) Received: from [209.85.220.54] (HELO mail-pa0-f54.google.com) (209.85.220.54) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 10:57:19 +0000 Received: by mail-pa0-f54.google.com with SMTP id fa10so76155pad.41 for ; Tue, 05 Feb 2013 02:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=B0AyjpWWttS8+VF1xy8/iuzinSD+Ct88YucNw0g3f4E=; b=oXXAWDRMUppIvjVEhFb7XLM7UHgBaBTarwn4gF8EO8M6Kpdy9PFkmd7xd3CxkNapjd pm76xO2UnZMEjzOzhmbcllHS0J58hDzxiQM5DyTjNFjY4egkbJQDzjsNMa/cd4eMbTfY lQLrfwXX4nNiaDb39XNCF5F4lci7b9eAWZcozR9pBolslYII41aRt4r8MOF5waQE25ru f6LzL+k6cHhDiFC1iy1UUnb3ETx+yGXtJ/ucOP6fo+KcUHJdpWiGyVb/2T83FSwois1P UAlDv91+ApD52GbmYi/0FfmaYx0FjBtSV7aJomPuff+noolFk65mr9JJeYQXw+U4EGXU nVKQ== X-Received: by 10.66.88.164 with SMTP id bh4mr63194211pab.41.1360061818069; Tue, 05 Feb 2013 02:56:58 -0800 (PST) Received: from [192.168.1.100] ([124.43.82.58]) by mx.google.com with ESMTPS id m3sm28512494pav.4.2013.02.05.02.56.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Feb 2013 02:56:56 -0800 (PST) Sender: Asankha Perera Message-ID: <5110E574.8060100@apache.org> Date: Tue, 05 Feb 2013 16:26:52 +0530 From: "Asankha C. Perera" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: HttpComponents Project Subject: Re: Question on HC Connection pooling - PoolEntry References: <510CB602.7030704@apache.org> <1359831274.20832.9.camel@ubuntu> In-Reply-To: <1359831274.20832.9.camel@ubuntu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi Oleg >> public synchronized void updateExpiry(final long time, final TimeUnit >> tunit) { >> Args.notNull(tunit, "Time unit"); >> this.updated = System.currentTimeMillis(); >> long newExpiry; >> if (time > 0) { >> newExpiry = this.updated + tunit.toMillis(time); >> } else { >> newExpiry = Long.MAX_VALUE; >> } >> this.expiry = Math.min(newExpiry, this.validUnit); >> } >> > Hi Asankha > > Let's say a pool entry is created at 10:00 with the total time to live > of 10 minutes. The validUntil value is set to 10:10. Let's say at 10:05 > #updateExpiry takes 10 minutes as input thus making newExpiry equal to > 10:15. Should not validUntil still apply and take precedence over > newExpiry? > > Oleg That's what I was wondering, and I thought the newExpiry should take precedence, since each time I re-use a connection, I'd typically want to extend its life time. I guess re-using connections is my objective when using a connection pool, and thus, with each re-use the life time should extend, unless some request causes a connection close or non-reusable event where its discarded. When I created the original connection I state that it can be reused within another 10 minutes - i.e. until 10:10. When I do re-use it at 10:05, if I am to call updateExpiry() again, that indicates that I want to now "update" the expiry time which is currently set. Now if I say I want to re-use this again in the next 10 minutes, i.e. until 10:15, the new expiry time should be the max of validUntil and newExpiry thanks and regards asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org