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

re: ITS#3549, abandon/cancel/unbind

At 03:33 PM 6/17/2005, Howard Chu wrote:
>I'm still questioning the current code (from connection.c rev 1.265) which removes some of Abandon's exemptions from the defer check. Since ultimately processing the Abandon will free up resources.  I think it should always go through, and we need to give the same treatment to Unbind.

Some of the restrictions were put in place for non-obvious reasons.
For instance, one of the reasons we defer Abandon during Bind is
because the Bind operation itself is not abandonable.  Of course,
clients which issue requests while Binding, especially non-anonymous
Binds, are quite broken.  Which is another reason I never paid
much attention to this case.

If we place some restrictions on what kind of operations abandon
can abandon, then we give some more exemptions to Abandon.
For instance, if we restrict abandoning to only search requests,
then things get easier.  (Cancel can cancel more (but
not all) kinds of operations.  But let's take on separately.)

And, as far as thread restrictions, I disagree that an exemption
should be given.  Abandon will use additional resources to do
its work, and that's why the thread restriction should apply.

>I'm not sure we can do anything about Cancel since we haven't parsed the request OID by the time we make the decision about deferring the operation. We could try parsing the OID earlier but that seems ugly. It also seems like a minor issue, and we can just leave things the way they are. It seems the main reason Cancel was implemented here was to allow terminating a Persistent Search operation, and for that purpose it will still work fine.

The main purpose of Cancel is replace completely the function
of Abandon, which suffers from not having any indicator of
success or failure.  Of course, Cancel (and Abandon) are
generally only useful when the operation is log-lived, such
as a subtree search, a subtree rename, or some chained
operation (in which case, the cancel should be chained).


>-- 
> -- Howard Chu
> Chief Architect, Symas Corp.       Director, Highland Sun
> http://www.symas.com               http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support