[SSSD] LDAP connection tracking, sharing and fail-over retry framework

Stephen Gallagher sgallagh at redhat.com
Thu Jun 17 12:53:39 UTC 2010


On 06/17/2010 08:32 AM, Eugene Indenbom wrote:

> TALLOC library has changed meanwhile. TALLOC version 2 uses typed
> destructors. Just take a look into talloc.h and see how type safety is
> implemented using simple macros and modern gcc features.

I wasn't aware of that, but it still means that we're using features 
that may not be available in all dependent platforms (I don't know if 
Debian is using libtalloc2 yet, for example) At minimum, if we're going 
to change to this style we need to update our configure scripts to 
detect an appropriate talloc version.

> What I have done looks OK for me. I am setting timeval not to offset,
> but first to connection expiration time (absolute time in seconds from
> EPOCH):
> tv.tv_sec = conn_data->sh->expire_time;
> Then I subtract LDAP query timeout from it:
> tv.tv_sec -= timeout;
> I assume that connection should be dropped from cache if it will expire
> before query time-out.
>

Sorry, I misread. I thought conn_data->sh->expire_time was a number of 
seconds, not an exact time.


> I agree that it's better to move to next server after current one
> failed, but it is not acceptable to mark current server as not working
> just because of broken connection as there is a good change that it was
> a recoverable problem like expired GSSAPI ticket. Unfortunately
> fail-over API currently does not have such functionality.
>
> So I would propose to make a separate patch which will add such a
> functionality to fail-over and then use it in sdap_id_op_done when
> broken connection is detected.

Ok, do you want to do this (or at least scope out the exact changes you 
want to see)?


> I do not agree that short-circuiting in this case is not worthwhile.
>  From my point of view, overhead of allocating request and
> tevent_request_post should be avoided.
>
> But anyway, changed it to full tevent style compliance.

In general, being able to follow the same execution path in either 
situation makes the code more maintainable. This is worth the minimal 
overhead here (tevent_req_post() implements a tevent_req_immediate() 
call, so it's not going to wait for another loop or anything)

> The modified patches are attached. As last time the changes were not
> tested, just compiled. If they look OK, the next step for me would be to
> convert all the remaining code in series of patches and test the result.

Ok, I'll give them another look either tomorrow or first thing on Monday 
(I have a lot on my plate today). Thank you very much for your hard work!

-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



More information about the sssd-devel mailing list