On 3/16/06, Brad Nicholes <[EMAIL PROTECTED]> wrote: > >>> On 3/16/2006 at 7:12 am, in message > <[EMAIL PROTECTED]>, "Jeff > Trawick" > <[EMAIL PROTECTED]> wrote: > > On 3/16/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote: > >> > >> > >> On 03/16/2006 03:49 AM, Jeff Trawick wrote: > >> > On 3/15/06, Brad Nicholes wrote: > >> > >> > > >> > That is really one pool globally but there is a mutex per > server_rec. > >> > So a thread handling a request for one vhost grabs the mutex and > uses > >> > the pool but that doesn't protect from a thread handling a request > for > >> > a different vhost which grabs a different mutex supposedly > protecting > >> > the same pool. > >> > >> Would it help to create sub-pools per server_rec from the config > pool? > > > > That sounds like a definite improvement, but I'm eager for LDAP > gurus > > to explain how pool growth is mitigated in the current design > > (assuming thread safety) before jumping to a conclusion > > The use of the pool is actually fairly limited. It is used to create > and initialize the reusable LDAP resources such as ldap connections. > The pool of ldap connections can grow but that is based on the amount of > traffic that requires LDAP authentication. Even under very heavy use, > the number of connections in the connection pool might be ~20 but even > that is a generous number.
if ldap server times out the connection and we have to bring one back up, that is no pool growth, right? we just get pool growth when we talk to an LDAP server we haven't already talked to yet, or when? > Any per-request memory allocations are done > from the request pool. So the potential for collisions within the > global memory pool, although not 0, would be very low. "very low" == still broken but much much harder to debug than "high" > > The purpose of the mutex is not necessarily to protect the memory pool > but to protect the ldap connection pool. Whenever mod_ldap needs to > pull a connection from the ldap connection pool, it first grabs the > mutex so that it is free to search for a connection and modify its > parameters without having to worry about other threads doing the same > thing. Since most of the global memory pool usage, outside of module > initialization, also occurs after the connection pool mutex has been > locked, this also lessens the chance of memory pool collisions. > > However, given all of there, I still think that there are things that > need to be cleaned up especially with the mutex allocation and use in a > worker MPM environment. I interpret this as meaning that the following would resolve the problems (race condition for mutex initialization between multiple threads for the same vhost and race condition for pool use between multiple threads in different vhosts): 1) this code needs LDAP-specific subpool of pchild* for each LDAP-enabled vhost, initialized in child-init hook 2) the vhost-specific mutex is initialized in the child-init hook (walk the server_rec list) *do these objects need to get cleaned up when the process goes away? maybe it shouldn't be a subpool at all but instead a freestanding pool (I can't remember at the moment if a freestanding pool keeps it from being cleaned up at child process exit) or 1) one global subpool of pchild* for each LDAP-enabled vhost, initialized in child-init hook 2) one global mutex initialized in the child-init hook It just depends on expected collision rate. I see some pthread_mutex_trylock usage, which makes me think the collision rate can be high, but it is unclear that segregating by vhost makes much of an improvement.
