On 14/05/2016 12:26 a.m., asakura@xxxxxxxxxxxxx wrote: > Hello, > > Thank you always for your kind support. > > I testing squid-3.5.19 "max_user_ip/authenticate_ip_ttl" feature. > but, access control not work well. > (Value of authenticate_ip_ttl is not enable) > > I investigating, and tried to change as follows. > > src/auth/User.cc > ---- > # diff User.cc.org User.cc > 287c287 > < ipdata->ip_expiretime = squid_curtime; > --- >> ipdata->ip_expiretime = squid_curtime + ::Config.authenticateIpTTL; > ---- > > Is this would be correct change? No. That particular data cache is one in Squid that works on a very weird staleness orientation rather than freshness. Caches that work on freshness behave like one would expect. Things start out fresh and grow towards some TTL 0 point where the flip to being stale and can be removed or replaced. But these weird staleness oriented things start out at some origin point in time (squid_curtime) and just continue to get more and more stale. Operations that need to be done on them can use multiple and different TTL offsets, which change over time (for example on reconfigure) without affecting the cached objects. It is up to the logic doing that operation to check the staleness against the right TTL. You can see this in Auth::User::cacheCleanup() which applies authenticate_ip_ttl to see what can be erased. Compared to the Auth::User::absorb() which compares two lists of objects against each other and drops from one list anything that is not brand new (current second). I suspect bugs you are seeing are in that absorb operation since it is timing-critical and happens with an async delay in the middle of the list being created and method happening. If you want to help out with that whole mess there, please discuss intended changes on squid-dev mailing list where the other dev are sure to see your proposals. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
