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!