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

Eugene Indenbom eindenbom at gmail.com
Thu Jun 17 13:00:30 UTC 2010


On 06/17/2010 04:53 PM, Stephen Gallagher wrote:
> 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.
>    
Will change it back to untyped. No problem.
> <...>
>
>    
>> 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'd like to do it myself. It looks like very simple change: just move 
current server pointer to the next record in the list.
>> 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)
>
>    
Looking at the new code version, I am inclined to agree with you. :)




More information about the sssd-devel mailing list