On 3/16/06, Brad Nicholes <[EMAIL PROTECTED]> wrote:
> >>> On 3/16/2006 at 7:01 pm, in message
> <[EMAIL PROTECTED]>, "Jeff
> Trawick"
> <[EMAIL PROTECTED]> wrote:
> > On 3/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> >> URL: http://svn.apache.org/viewcvs?rev=386477&view=rev
> >> Log:
> >> remove the race condition when creating the connection pool mutex.
> Also
> > eliminate some unnecessary uses of the global memory pool
> >
> > cool!
>
>
> >> @@ -1753,7 +1753,10 @@
> >>      util_ldap_state_t *base = (util_ldap_state_t *) basev;
> >>      util_ldap_state_t *overrides = (util_ldap_state_t *)
> overridesv;
> >>
> >> -    st->pool = p;
> >> +    st->pool = base->pool;
> >> +#if APR_HAS_THREADS
> >> +    st->mutex = base->mutex;
> >> +#endif
> >
> > What this use of the base pool and mutex means is that while a
> subpool
> > and mutex were created for the vhost, we'll never use them.
> Instead,
> > we'll use the subpool and mutex created for the main server.
> >
> > Not what you meant, right
>
> I guess I don't understand.  When I tested this using the worker MPM (3
> servers, 25 threads each) and configuring both an ldap protected
> directory in the main server and an ldap protected directory in a vhost,
> it never had a problem locking the mutex or allocating memory.   Am I
> missing something?

You won't see any functional problem.  You're just not using some of
the pools and mutexes you created.

Example:

Here are some vhosts:

<VirtualHost *:8080>
ldapcacheentries 200
</VirtualHost>

<VirtualHost *:80>
ldapcacheentries 100
</VirtualHost>

util_ldap_create_config() gets called 3 times to create the
vhost-specific configuration for mod_ldap (once for main server scope
and once for each vhost).  Each time, you create a subpool and a mutex
to be used for that vhost/server_rec.

After the create-config is called, next the merge function
util_ldap_merge_config() is called twice to merge the main server
scope server_rec with each vhost server_rec.

The first time it is called, basev points to the main server_rec, and
overridesv points to the server_rec with ldapcacheentries set to 200. 
Normally a merge function will have logic like:

  if value not set in overrides server_rec
    overrides->value = base->value

But this merge function ignores information in the overrides
server_rec (e..g, the one with "ldapcacheentries 200" and its own
specific pool and mutex) and writes over the values with the main
server values.

After the merge function is called twice (once per vhost), both vhost
containers have had the pool and mutex wiped out and all requests will
use the pool and mutex for the main server_rec.

Other (original) code in this merge function looks wrong too:

  st->cache_bytes = base->cache_bytes;

OTOH, some code looks like it is working properly:

  st->secure = (overrides->secure_set == 0) ? base->secure
                                                         : overrides->secure;

Reply via email to