On Tue, 14 Sep 2004, [ISO-8859-15] Andr Malo wrote:
* Paul Querna [EMAIL PROTECTED] wrote:
(chop)
Using the Source File name seems completely non-intuitive to me.
Agreed.
I'm rather for removing the whole crap from the default config and simplifiy
as much as possible.
I'd be cautious
Jess Holle wrote:
Okay, the cause of this issue is now clear:
util_ald_create_caches() does not set 'newcurl' to anything when any
of the caches are null, which they all are when they're sized at zero.
The fix is also simple: add an 'else newcurl = NULL;' after the 'if'
block in this
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
Graham Leggett wrote:
Jess Holle wrote:
Okay, the cause of this issue is now clear:
util_ald_create_caches() does not set 'newcurl' to anything when any
of the caches are null, which they all are when they're sized at
zero.
The fix is also simple: add an 'else newcurl = NULL;' after the
Jess Holle wrote:
Just a note: this was enough to fix the problem without the global
mutexes present -- I've not tested again with the mutexes present as I
want to get to the bottom of the cache overflow crashes first if I can.
The fix should still go in anyway as leaving this uninitialized
Graham Leggett wrote:
Jess Holle wrote:
Just a note: this was enough to fix the problem without the global
mutexes present -- I've not tested again with the mutexes present as
I want to get to the bottom of the cache overflow crashes first if I
can.
The fix should still go in anyway as leaving
I now see what's wrong with the LDAP cache purge -- it does not fix up
the 'next' pointers and/or cache-node[i] pointers when removing entries
-- and thus cannot hope to work.
Unfortunately, my fixes for this are still falling short, but I thought
I'd pass this along.
--
Jess Holle
Jess Holle wrote:
I now see what's wrong with the LDAP cache purge -- it does not fix up
the 'next' pointers and/or cache-node[i] pointers when removing entries
-- and thus cannot hope to work.
Unfortunately, my fixes for this are still falling short, but I thought
I'd pass this along.
Looking
Graham Leggett wrote:
Jess Holle wrote:
I now see what's wrong with the LDAP cache purge -- it does not fix
up the 'next' pointers and/or cache-node[i] pointers when removing
entries -- and thus cannot hope to work.
Unfortunately, my fixes for this are still falling short, but I
thought I'd
Another dumb question:
On Windows since there is only one child process, wouldn't it make sense
to stick with the read/write locks and not move to a global mutex?
In the multi-child mpms, the global mutex is obviously required, of course.
--
Jess Holle
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
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
Here's one final patch to fix the global mutex crash when the global
mutex is never allocated due to disabled/empty caches.
I would really like some clarity as to whether:
We should just stick with the single-process read/write lock for
single-worker MPMs. It would really seem so.
Jess Holle wrote:
Here's one final patch to fix the global mutex crash when the global
mutex is never allocated due to disabled/empty caches.
I would really like some clarity as to whether:
We should just stick with the single-process read/write lock
for
single-worker MPMs. It
Jess Holle wrote:
Jess Holle wrote:
Here's one final patch to fix the global mutex crash when the global
mutex is never allocated due to disabled/empty caches.
I would really like some clarity as to whether:
We should just stick with the single-process
Sorry. One last post...
It seems that at least on Windows if I place
Location /server/cache-info
SetHandler ldap-status
/Location
too early in the configuration Apache crashes on shutdown.
Specifically, if I place it in front of my mod_deflate configuration
(similar to that in
With mod_logio enabled on a 404 response, the final
output brigade sent down the filter stack consists of
a single EOS bucket. In this circumstance mod_logio's
logio_out_filter() calls APR_BUCKET_INSERT_BEFORE on
the sole eos bucket, which corrupts the brigade and
sometimes causes httpd to
18 matches
Mail list logo
