Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 30870 invoked from network); 20 Sep 2004 18:08:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 20 Sep 2004 18:08:22 -0000 Received: (qmail 17694 invoked by uid 500); 20 Sep 2004 18:08:15 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 17640 invoked by uid 500); 20 Sep 2004 18:08:14 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 17615 invoked by uid 99); 20 Sep 2004 18:08:13 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [137.65.81.169] (HELO sinclair.provo.novell.com) (137.65.81.169) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 20 Sep 2004 11:08:12 -0700 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 20 Sep 2004 12:08:11 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Mon, 20 Sep 2004 12:07:52 -0600 From: "Brad Nicholes" To: , Subject: Re: Apache 2.0.51 util_ldap Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 500/1000/N >I'm still wondering if we shouldn't just stick with the local read/write >lock on Windows and other single child MPMs (NetWare?) as this should >allow better throughput in such cases and yet be safe, right? In fact, Actually on NetWare this is a non-issue. On NetWare everything is global (memory, locks, etc.), so there is no difference between a global mutex and a local one (other than previously we were using reader/writer locks rather than mutexes). I would like to use reader/writer locks rather than global mutexes simply for performance reasons, but I'm not sure how we would go about switching between global and local locks anyway. This would require #ifdef'ing the code for particular platforms or MPM's which isn't a good thing. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> jessh@ptc.com Sunday, September 19, 2004 3:43:20 PM >>> Sorry for the chattiness of my solution process. I've tested and these fixes do apply with the global mutex changes *except* when one disables caches by sizing them all to 0, Apache will crash on the first authentication request when the global mutexes are used! This needs to be fixed! I've attached a unified diff containing the purge fix and the unassigned variable fix (which as Graham pointed out is already in the 2.1 branch). I'm still wondering if we shouldn't just stick with the local read/write lock on Windows and other single child MPMs (NetWare?) as this should allow better throughput in such cases and yet be safe, right? In fact, why do we use shared memory on these platforms for the cache? [If I'm just daft here, I apologize.] -- Jess Holle Jess Holle wrote: > Here's a fixed LDAP purge routine which works great in my testing > (with cache sizes of 8, 100, 1000, and 2150 and 2500 unique user > logins repeated 3 times each). [No, I haven't produced a diff as I > have pieces of util_ldap from various CVS levels at this point.] > > Essentially I added all the logic surrounding 'pp', which is the > address of the previous node's 'next' field or of cache->nodes[i] in > the case of the first node. [Cleary my C is getting rusty -- this > took me a few attempts to get right...] > > This fixes the biggest LDAP module issue I'm aware of: hangs and > crashes after one or more cache purges.