I seem to have missed this email yesterday, sorry about that, Alex. I found
it today, thankfully. :-)
On May 22, 2013, at 12:55 , Alex Rousskov wrote:
> Yes, fastCheck() does not support slow ACLs. To be more precise, Squid,
> depending on the version and the slow ACL type, may "call" that slow ACL
> during a fast check, but that call will fail as far as ACL matching is
> concerned if a slow/non-blocking lookup is required to evaluate the
> match. If a slow ACL can be matched in a fast mode (e.g., due to
> previous ACL results caching), the match may succeed. In other words, a
> documented-as-slow ACL may work as a fast one, depending on Squid state.
hehe. Nothings ever completely simple, eh? But thank you for the detailed
explanation.
> There are two reasons getOutgoingAddress code is using fastCheck()
> instead of nonBlockingCheck():
>
> 1. The code using fast checks is much easier to write.
>
> 2. Fast checks are faster,
> even when no slow ACLs are used in a nonBlockingCheck().
>
> The second reason is a relatively weak one -- I do not recall any cases
> where a patch offering fast-to-nonblocking conversion was rejected on
> performance grounds alone. However, it should probably be rejected
> without a good use case. This is especially true for getOutgoingAddress
> checks because they may perform fastCheck calls multiple times.
>
> Please note that a correct conversion is not trivial because one has to
> save the current state of the caller and restore it in the non-blocking
> callback, dealing with all the usual async code complications. The
> getOutgoingAddress() code conversion would be especially tricky because
> it calls fastCheck in a loop!
In reading this, I was about to ask "why is it complicated?" but you answered
that. Thank you. So, there isn't a variant of fastCheck that simply _will_
call the slow acl mechanism, without having to deal with the async mechanisms
apparently in play with nonBlockingCheck()? For my needs, I'm going to need
to modify getOutgoingAddress in the end anyway, so I've no issue changing
that code. But, I see also your notes about how it would be complicated to use
nonBlockingCheck().
> If your external ACL can make a decision earlier (e.g., during
> http_access checks), then you can use helper annotations API to record
> that external ACL decision as annotations and then use a "note" ACL to
> pick the right outgoing address depending on the previously recorded
> annotations. The "note" ACL is fast.
>
> This solution is available for a patched trunk-based code. Numbered
> releases do not support the "note" ACL yet, and the trunk patch
> acceptance got delayed due to new features being added to the project
> scope during patch review on squid-dev. See the "note acl" thread.
I'd be comfortable running with a patch. Especially since by the time I
finish all of this project, it'll likely at least have made it to trunk. (One
would
hope)
I think my external acl can make it's decision as soon as the destination
address is known, which would be available at http_access times. I'll take
a look into helper annotations. Thank you for the pointer. If you have any
more specific advice, or a pointer to the "note acl" thread, those would be
appreciated as well.
- Chris
