From users-return-3749-apmail-directory-users-archive=directory.apache.org@directory.apache.org Thu Feb 24 17:02:01 2011 Return-Path: Delivered-To: apmail-directory-users-archive@www.apache.org Received: (qmail 26037 invoked from network); 24 Feb 2011 17:02:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Feb 2011 17:02:01 -0000 Received: (qmail 62546 invoked by uid 500); 24 Feb 2011 17:02:01 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 62416 invoked by uid 500); 24 Feb 2011 17:01:58 -0000 Mailing-List: contact users-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@directory.apache.org Delivered-To: mailing list users@directory.apache.org Received: (qmail 62408 invoked by uid 99); 24 Feb 2011 17:01:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Feb 2011 17:01:58 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com designates 209.85.161.50 as permitted sender) Received: from [209.85.161.50] (HELO mail-fx0-f50.google.com) (209.85.161.50) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Feb 2011 17:01:51 +0000 Received: by fxm18 with SMTP id 18so999319fxm.37 for ; Thu, 24 Feb 2011 09:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VNPDOWsT3O27OsmPTPqnEbGWhY2r62l0T8M4trxvnZE=; b=sGUMr9m5ODW4r3JGtEaiMUFLhmyRph+um2yq2+AQ/GBF6Z7rjAxUupnTBkJRz/GVC4 pBOOqtRFHfLoMXLARATu8OGinyXkm9Hy7UFd9Tep53FkXd3LOcjOjucerwyZ49gSKgCy iSV4G1Y6DsDzsZ0RkvjcSSwZBEmw9E7XFQzUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=AdtzPLsYSSKW5lL1oz1mQnMqJiXVXkpTRdfp4wQYcNDmVpNCg5orjRwbEHMzoewifD 0+QvkErAmZ3tBtZ9FcLJZpDEao7yeZGn8lsc7HSOBjlNcssie+krviaWsTyxOC8HOe2/ sxhDGXsnVZQL4GVduwnEGwtK/QBOAShVc+KYw= Received: by 10.223.74.15 with SMTP id s15mr1341389faj.28.1298566642959; Thu, 24 Feb 2011 08:57:22 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (lon92-10-78-226-4-211.fbx.proxad.net [78.226.4.211]) by mx.google.com with ESMTPS id e17sm1817304fak.34.2011.02.24.08.57.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Feb 2011 08:57:20 -0800 (PST) Message-ID: <4D668DED.6020707@gmail.com> Date: Thu, 24 Feb 2011 17:57:17 +0100 From: Emmanuel Lecharny Reply-To: elecharny@apache.org User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: users@directory.apache.org Subject: Re: How to close the LDAP client connection from ApacheDS References: ,<4D667369.5000007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/24/11 5:32 PM, Ado Dao wrote: >> Also not that if you are on linux, the default number of handles you can >> open is 1000, which is far too low for a LDAP server, assuming you might >> have ten of thousands opened connections. Tune your system. > > I also agree you. But I > suspect that the number of > open connections is steadily increasing, because > the error occurred after several days. After a > restart the ldap server it was OK. > > It looks like some > clients do not terminate > the connection. Therefore, the > question whether there is > an option for the > server, which terminates such > open connections after a timeout. If the client disconnect without notice, yes, the connection will remain until we detect it. One option would be to tune the TCP stack to close idle connections. Usually, it's set to 30 minutes. Regarding the support of idle connection in the server, I don't think we handle that atm, but it would be a good addition. Feel free to create a JIRA, it should not be a complicated modification in the server to handle idle connections with a configurable timeout. Also note that due to the connected nature of LDAP, one client might be connected for a very long time without sending a new request, so be very conservative with such a configuration. Establishing a connection is costly and requires you store the credentials on the client, when manaing tens of thousands connection which do nothing is just a no brainer... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com