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/