Re: mod_ldap Cache Issues
Hi Jess, Did you used the patch i did and i posted here and on bugzilla for bug #18756 ? For your first issue, the problem should be that all memory allocation are not controlled in the code, i mean if it return NULL or an address to the memory, it's the same. So maybe when you are at user 376, you allocated all the memory of the ldap_cache, and it's unable to give more, but it continue as it was ok. I am actually working on this problem, this issue is maybe the source of the next problem too. For issue 2, it seems to be a bad unlock when you reach the maximum user limit, i will look this too. Jess Holle wrote: I have been using Apache 2.0.47 on Windows with util_ldap and mod_auth_ldap for some time, but never heavily. I populated an LDAP directory with thousands of users, placed a 25K static HTML page in a directory configured to "require valid-user" against the LDAP in questiono, and then did a simple test involving GET's for the given page as randomly selected users. I quickly ran into an issue: ISSUE 1: Every run Apache would crash when the 376th (distinct) user attempted to authenticate. This occured at that number regardless of how many requests had been made on behalf of each user. This *appeared* to be due to the size of my particular URLs, DNs, user names, etc, exceeding the physical memory allocated by 'LDAPSharedCacheSize' before the given number configured number of cache entries were exceeded. I was using the defaults for all LDAP cache parameters, i.e. I was not specifying anything in my conf files. I say *appeared* as the crash would occur while trying to allocate memory for a new cache entry. I looked and it appears that none of the code appears to handle the case where the share memory block is exhausted (e.g. by gracefully not adding an entry to the cache and deallocating any portion of a new entry that has been allocated up too that point -- or by freeing older entries and retrying). I did some quick back-of-the-envelope estimates and decided that the default 10 bytes may well have been used up. I computed that my entries appeared to be consuming about 267 bytes a piece if this was the case and increased LDAPSharedCacheSize accordingly for the number of distinct users making requests in the test. Right or wrong, this approach worked great for a single-threaded test. I then tried 8 threads in parallel making requests. This worked great as well. All of this was with the actual number of distinct users being less than the configured cache sizes, however. I then tried the tests with the number of distict users being larger than the cache sizes at which point I ran into a more serious issue: ISSUE 2: Apache would consistently pause significantly on the 1025th distinct user (with the caches set to hold 1024, i.e. the default). Sometimes it would recover, but invariably it would completely deadlock shortly thereafter. Using the status page it appears that most times there is a deadlock on the first purge attempt and a deadlock always occurs on a purge request soon thereafter. This issue seemed independent of the cache limit, i.e. I could set the cache entry limit to 5 and Apache would deadlock after a few purges there as well (though a few seemed to occur rather quickly first whereas at 1024 purges seemed very slow even when they succeeded). I say Apache was deadlocked in that all the threads that were processing connections were trying to establish a lock on the LDAP cache -- and none appeared to be successfully holding it. From a look at the code I infer that the author is trying to allow many readers with little synchronization but ensure at most one writer (and no readers during this writer's operation), but it does not seem to be quite working that way. I ran into similar issues to this deadlock with Apache 1.3.28 (EAPI_MM) and auth_ldap 1.6.0 (with a shared cache) on Solaris 8. I could not ellicit any such failure conditions from HP Apache 1.0.06.01 (their latest bundle of 2.0.46) but I've not tried these tests with Apache 2.0.x on other platforms. Does anyone have any brilliant ideas here? I'm planning to disable the util_ldap cache in all the problematic cases (i.e. on Windows until knowing the maximum number of users and on Apache 1.3.x as a whole) for now as I don't have that deep of an understanding of the code here -- short as it is -- and may not have the time to attain such an understanding for a while -- Jess Holle
Re: [proposal] styleguide tweak
On Fri, Oct 03, 2003 at 12:07:23AM -0400, Cliff Woolley wrote: >... > I am NOT saying opening braces can or should be on their own line for > regular code. ONLY when they follow a conditional expression that spans > lines. I'd prefer they get their own line all the time :-), so I'll certainly agree with the sentiment of requiring them after a multi-line conditional. The rationale for the style guide here is simply that the extra whitespace "terminates" the multi-line conditional for the reader. [ my personal opinion is that the whitespace is always needed so the reader doesn't mistake the code for a multi-line conditional ] Note: I'm not desiring to raise a debate or change the style. Merely supporting the notion that a line of almost-whitespace should occur after the multi-line conditional. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [proposal] styleguide tweak
Greg Stein wrote: On Fri, Oct 03, 2003 at 12:07:23AM -0400, Cliff Woolley wrote: ... I am NOT saying opening braces can or should be on their own line for regular code. ONLY when they follow a conditional expression that spans lines. I'd prefer they get their own line all the time :-), so I'll certainly agree with the sentiment of requiring them after a multi-line conditional. well, I can certainly understand that up to a point... long ago the product I was working on adopted a style with opening brace always on its own line, and I adjusted my brain as appropriate, and it feels natural *in the scope of other code following similar style*... and of course opening brace on its own line is the one true way since it is consistent with the first brace of a function one true way or not, consistency with other style guidelines for this body of code and the bulk of existing code is more important, and I think this special case handling of the opening brace is going to be a wart... doesn't match aesthetically, and is an extra rule that doesn't solve a problem that a number of people have encountered but I don't really want to argue either, just put up my 2cents and then shut up I'm really done :)
Re: [proposal] styleguide tweak
Cliff Woolley wrote:
On Thu, 2 Oct 2003, Jeff Trawick wrote:
I'm quite happy that
[httpd-2.0] $ find . -name '*.c' | xargs grep '^[ \t]+{'
currently produces no output, and I'd prefer that it stay that way ;)
That it does, but
[httpd-2.0] $ find . -name '*.c' | xargs egrep '^[ \t]+{'
(note the 'e' on egrep) produces quite a lot of output, much of which is
the kind of thing I'm talking about.
and much of which, it is fair to point out, are structure definitions :)
dang, why does
grep '^{'
work for finding opening braces at the beginning of the line, but
grep '^ +{'
not work for finding opening braces after at least one space?
oh, shoot... + is not handled by default with grep
okay, really shutting up now...
Re: [proposal] styleguide tweak
Jeff Trawick wrote: one true way or not, consistency with other style guidelines for this body of code and the bulk of existing code is more important, and I think this special case handling of the opening brace is going to be a wart... doesn't match aesthetically, and is an extra rule that doesn't solve a problem that a number of people have encountered As much as I would like to have all the code formatted according to the the "one true way" (my personal preference), I have to agree with Jeff that it should be all or nothing rather than with special exceptions. Since the code is all formatted in !"one true way" I'd have to vote to keep it that way. IMHO, an exception for multiline conditionals would just confuse things. Now if we want to talk about reformatting *all* the code to the "one true way"...:)*duck* -- Paul J. Reder --- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
Re: mod_ldap Cache Issues
Matthieu Estrade wrote: Hi Jess, Did you used the patch i did and i posted here and on bugzilla for bug #18756 ? No, I didn't. I must admit that it is difficult to spot the info (tree) for the forest at times -- at least for me, though I notice I did comment on this and am already cc'ed on this bug. I guess I had been hoping that any necessary patches of this magnitude would be wrapped into a release by this point. I have not yet gotten any core dumps, though a co-worker did *once* -- and has not been able to reproduce it. Also all works fine as long as I don't exceed the alloted shared memory (annoying, but livable) or the cache entry limit (this is the real kicker as I can't predict this for all our customers and many of them can't predict it either). Finally HP claims that they're using stock 2.0.46 in this regard and their mod_ldap works fine (with mod_worker). For your first issue, the problem should be that all memory allocation are not controlled in the code, i mean if it return NULL or an address to the memory, it's the same. Yep. So maybe when you are at user 376, you allocated all the memory of the ldap_cache, and it's unable to give more, but it continue as it was ok. I believe that's what it's doing. I just wasn't able to get the debugger stopped right in the act -- only after this *appeared* to have occured. Looking at all the information, however, everything strongly points in this direction. I am actually working on this problem, this issue is maybe the source of the next problem too. For issue 2, it seems to be a bad unlock when you reach the maximum user limit, i will look this too Thanks! -- Jess Holle
Re: [proposal] styleguide tweak
Paul J. Reder wrote: Jeff Trawick wrote: one true way or not, consistency with other style guidelines for this body of code and the bulk of existing code is more important, and I think this special case handling of the opening brace is going to be a wart... doesn't match aesthetically, and is an extra rule that doesn't solve a problem that a number of people have encountered As much as I would like to have all the code formatted according to the the "one true way" (my personal preference), I have to agree with Jeff that it should be all or nothing rather than with special exceptions. Since the code is all formatted in !"one true way" I'd have to vote to keep it that way. IMHO, an exception for multiline conditionals would just confuse things. I have to agree. Now if we want to talk about reformatting *all* the code to the "one true way"...:)*duck* Definitely not, for all the reasons mention by Dean Gaudet in many past posts. Bill
Re: adding map_to_storate to mod_example.c
Greg Stein wrote:
That's not much of an example. All it really shows is how to register a
hook. A better example would be to *use* the hook in some way.
whoops. I guess I did leave out the explanatory comments. outside of that,
it pretty much follows the example in almost all the other hooks by doing
nothing, so it probably doesn't make sense to add real functionality there
unless you want real functionality everywhere.
assuming mod_example is just meant to show all the hooks and how to hook
into them, new patch with comments attached.
--Geoff
Index: modules/experimental/mod_example.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/experimental/mod_example.c,v
retrieving revision 1.41.2.1
diff -u -r1.41.2.1 mod_example.c
--- modules/experimental/mod_example.c 3 Feb 2003 17:31:37 - 1.41.2.1
+++ modules/experimental/mod_example.c 3 Oct 2003 14:45:45 -
@@ -1096,6 +1096,28 @@
}
/*
+ * This routine maps r->filename to a physical file on disk. Useful for
+ * overriding default core behavior, including skipping mapping for
+ * requests that are not file based.
+ *
+ * The return value is OK, DECLINED, or HTTP_mumble. If we return OK, no
+ * further modules are called for this phase.
+ */
+static int x_map_to_storage_handler(request_rec *r)
+{
+
+x_cfg *cfg;
+
+cfg = our_dconfig(r);
+/*
+ * We don't actually *do* anything here, except note the fact that we were
+ * called.
+ */
+trace_add(r->server, r, cfg, "x_map_to_storage_handler()");
+return DECLINED;
+}
+
+/*
* this routine gives our module another chance to examine the request
* headers and to take special action. This is the first phase whose
* hooks' configuration directives can appear inside the
@@ -1298,6 +1320,7 @@
ap_hook_default_port(x_default_port, NULL, NULL, APR_HOOK_MIDDLE);
#endif
ap_hook_translate_name(x_translate_handler, NULL, NULL, APR_HOOK_MIDDLE);
+ap_hook_map_to_storage(x_map_to_storage_handler, NULL,NULL, APR_HOOK_MIDDLE);
ap_hook_header_parser(x_header_parser_handler, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_check_user_id(x_check_user_id, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_fixups(x_fixer_upper, NULL, NULL, APR_HOOK_MIDDLE);
Re: Apache won't start - shared memory problem
Kris Verbeeck wrote: That won't solve the problem, the shared memory segment is still registered somewhere in the kernel. I've had lots of problems with this too and only deleting the file does not solve it. You have to remove the segments from the kernel table too (see mail from Paul). Is there no way that some cleanup process (whether it involves deleting a file, or talking to the kernel, doesn't matter) can be done before an attempt is made to create the shared memory segment? Regards, Graham --
Re: Apache won't start - shared memory problem
On Fri, Oct 03, 2003 at 06:47:16PM +0200, Graham Leggett wrote: > Kris Verbeeck wrote: > > >That won't solve the problem, the shared memory segment is still registered > >somewhere in the kernel. I've had lots of problems with this too and only > >deleting the file does not solve it. You have to remove the segments from > >the kernel table too (see mail from Paul). > > Is there no way that some cleanup process (whether it involves deleting > a file, or talking to the kernel, doesn't matter) can be done before an > attempt is made to create the shared memory segment? The issue is that APR creates the shmem segments using O_EXCL or IPC_EXCL etc. I think I've come to the conclusion that this should just be fixed in APR, MM does an unlink/shm_unlink on the filename first, and that doesn't cause any headaches I know of. joe
