[Freeipa-devel] threading issues

[Simo Sorce]

On Mon, 2007-10-08 at 10:58 -0400, Rob Crittenden wrote:
> Simo Sorce wrote:
> > On Mon, 2007-10-08 at 10:38 -0400, Rob Crittenden wrote:
> >> Kevin McCarthy wrote:
> >>> I wanted to put on the list to review threading issues.  Now that
> >>> we're using TG in a mod_proxy setting, we have to be concerned about
> >>> threading issues.
> >>>
> >>> Right now, the web gui is (incorrectly) allocating a shared IPAServer
> >>> object (by allocating a shared IPAClient).  Unfortunately there are two
> >>> issues here:
> >>>
> >>> 1) The self.princ and self.krbccache are being set on each request -
> >>>    which obviously won't work with multiple threads
> >>>
> >>> 2) The IPAConnPool isn't using locks around self.freelist
> >>>
> >>> The first change that has to happen is the web gui should allocate an
> >>> IPAClient for each request (I'll make that change).
> >>>
> >>> However, this loses any connection pool benefits.  To fix this, we could
> >>> separate IPAConnPool from IPAServer and implement Locks at the right
> >>> places.
> >>>
> >>> Any opinions?
> >>>
> >>> -Kevin
> >> It isn't really doing connection pooling anymore. Each connection is 
> >> created/torn down for each API call. The pooling was done when we were 
> >> binding using the SSL cert and using proxying.
> > 
> > Yeah I saw this in my mod_auth_kerb debug session now that I think of
> > it.
> > 
> >> We can't do pooling with kerberos because the credentials cache will 
> >> disappear when the current HTTP request is finished.
> > 
> > I find this contradictory, connection pooling usually means you keep
> > around an authenticated connection open. All you need to do is to keep
> > around information about the connection (the principal that opened it)
> > and reuse that if it matches.
> > Is there a problem keeping around connections with our current code?
> >
> 
> Don't be confused by the term pooling. As I said, I added that when we 
> punted on doing ticket forwarding. Prior to that it was one operation, 
> one connection.
> 
> Ok, now that I think about it further I suppose that since we are 
> already authorized the ccache is probably not necessary to close the 
> connection. It just seems wierd to have the keys taken away :-)

Does not need to be that way though, we can easily keep them around in a
cc file, just copy the CCache file somewhere else, maybe named after the
principal name. Just lets make sure it is removed when the connection
closes and that it is updated when a user re-authenticates.

> The problem keeping the connections around were outlined by Kevin. 
> Basically there is no locking. I mentioned at the time that this code 
> was lacking in many ways, it is just now time to pay the piper.

Yep when you do connection pooling you have to implement locking
mechanisms indeed.

Simo.