[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6103) canceled operations do not respond

Howard Chu writes:
> The tooLate reply is correct; back-null doesn't ever check for
> cancel/abandon therefore the operation is *not* successfully
> canceled. Likewise, back-bdb/hdb only checks in Delete if there is a
> transaction retry.

No difference if I use back-ldif, which does check for abandon.

> The lack of reply from the original op - that's a simple oversight. 
> send_ldap_ber() checks for op->o_abandon and returns silently if it's set. I 
> guess we need to also check for o_cancel to let it proceed.

The operation does not reach send_ldap_ber().  To verify, I temporarily
inserted assert(!op->o_abandon) just before send_ldap_ber()'s o_abandon
test.  send_ldap_response() notices both o_abandon and SLAPD_ABANDON,
and skips to the cleanup code in either case.

Also, backend operations that do return SLAPD_ABANDON - at least Search
in backglue and BDB - may do so without calling send_ldap_response() at
all.  Pierangelo made partial fixes in ITS#4645.  See also ITS#6059,
which I may have misunderstood somewhat.  (Sorry, Rein.)

Maybe o_abandon should only mean that:
- (a) the backend has been asked to abandon the operation,
- (b) slapd must check and react to o_cancel,
- (c) if not o_cancel, send_ldap_ber() need not send.