On 07/09/2010 05:28 PM, Simo Sorce wrote:
On Fri, 09 Jul 2010 15:01:17 +0400
Eugene Indenbom<eindenbom(a)gmail.com> wrote:
> If we do reconnect logic within sdap_generic_send, than after request
> for HBAC hosts is completed LDAP connection is released and could be
> dropped, as sdap_generic_send has no idea about second (HBAC rules)
> and third (HBAC services) requests that still needs to be processed.
>
Sorry I don't get this one. If sdap_generic_send fails midway then it
should restart itself, and if the connection is down when it is called
it should try to restart the connection itself before proceeding.
The point I was trying to make is that reconnections should be moved to
the lower level, so that less calls are involved in wrapping around
reconnects and retries.
The issue has nothing to do with reconnects. They actually can be solved
as level of sdap_generic_send. The problems are:
- using the same LDAP server for all requests in multi-stage
operation (discussed separately)
- LDAP connection caching. In your approach multi-stage operation
might drop cached connection in between of 2 LDAP requests. And approach
of having BE request level sdap_id_op avoids this as LDAP connection is
locked for full BE request duration.