[Freeipa-devel] threading issues

[Rob Crittenden]

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 :-)

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.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20071008/25f5711d/attachment.bin>