[squid-users] Debugging slow access
Steve Hill
steve at opendium.com
Tue Jan 6 12:15:48 UTC 2015
On 05.01.15 18:15, Amos Jeffries wrote:
> Can you try making the constructor at the top of src/HelperReply.cc
> look like this and see if it resolves the problem?
>
> HelperReply::HelperReply(char *buf, size_t len) :
> result(HelperReply::Unknown),
> notes(),
> whichServer(NULL)
> {
> assert(notes.empty());
> parse(buf,len);
> }
This didn't help I'm afraid.
Some further debugging so far today:
The notes in HelperReply are indeed empty when the token is added.
However, Auth::Negotiate::UserRequest::HandleReply() appends the reply
notes to auth_user_request. It fetches a cached user record from
proxy_auth_username_cache and then calls absorb() to merge
auth_user_request with the cached user record. This ends up adding the
new Negotiate token into the cached record. This keeps happening for
each new request and the cached user record gradually accumulates tokens.
As far as I can see, tokens are only ever read from the helper's reply
notes, not the user's notes, so maybe the tokens never need to be
appended to auth_user_request in the first place?
Alternatively, A->absorb(B) could be altered to remove any notes from A
that have the same keys as B's notes, before using appendNewOnly() to
merge them?
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com
Direct contacts:
Instant messager: xmpp:steve at opendium.com
Email: steve at opendium.com
Phone: sip:steve at opendium.com
Sales / enquiries contacts:
Email: sales at opendium.com
Phone: +44-1792-824568 / sip:sales at opendium.com
Support contacts:
Email: support at opendium.com
Phone: +44-1792-825748 / sip:support at opendium.com
More information about the squid-users
mailing list