Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 57455 invoked from network); 6 Jan 2008 20:07:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Jan 2008 20:07:23 -0000 Received: (qmail 74495 invoked by uid 500); 6 Jan 2008 20:07:12 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 74288 invoked by uid 500); 6 Jan 2008 20:07:11 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 74277 invoked by uid 99); 6 Jan 2008 20:07:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Jan 2008 12:07:11 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mark@scheduleworld.com designates 72.51.41.97 as permitted sender) Received: from [72.51.41.97] (HELO ns2.scheduleworld.com) (72.51.41.97) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 06 Jan 2008 20:07:00 +0000 Received: from 192.168.4.16 ([192.168.4.16]) by ns2.scheduleworld.com (JAMES SMTP Server 2.2.1-RC1) with SMTP ID 34 for ; Sun, 6 Jan 2008 15:06:41 -0500 (EST) Message-ID: <47813527.7030806@ScheduleWorld.com> Date: Sun, 06 Jan 2008 15:08:07 -0500 From: Mark Swanson User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: need socket auto-close References: <477FCC26.6070206@ScheduleWorld.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Alex Karasulu wrote: > I guess this is due to clients that do not unbind or stay connected > for a long time? You using persistent search anywhere? stay connected: Initially I thought so. After monitoring things for a day it seems this is the case. I'm not using persistent search, but quite a lot of different clients are connecting (I do not know how many types) and maybe one or more of them are. > In either case I would look into the LDAP protocol provider code. You > could hack the code so that a sweeper checks MINA sessions every now > and closes them if they have been idle for some time: there is a MINA > Session idleTime() or something like that to look up the idle time of > a session which represents the amount of time passed since data was > transmitted or received between the client and the server. Thank you. I have a feeling I may need to do that. I hope not. Cheers.