Control: reopen -1 Control: severity -1 wishlist On Fri, Mar 08, 2013 at 01:16:10PM -0500, Eric Cooper wrote: > There is a subtle difference between the "cached" and "delivered" log > messages. In both cases, the file is now in the cache. But > "delivered" means that the file was streamed back to the client > *while* it was being received from the remote repo and being written > to the cache; this is the usual case. "Cached" means that the > file was read from the repo in its entirety and cached *before* being > transferred to the client; this only happens when the remote repo uses > "chunked transfer encoding" and doesn't provide a content-length. > This is rare and that's the reason you don't see any of those log > messages.
Thanks for clearing this up. So "cached" is not what I'd like to see here. What I'd like to see is some indication that a file was delivered from the cache to the client. At the moment I can reliably reproduce that cache hits are not logged at all. So the reported issue persists. > > In addition it would be great to log the client requesting the file. > > This is done once per connection rather than on every request. > In the case of interleaved requests from multiple clients, you should > be able to thread them together by using the process id in the log > message, since inetd will spawn a separate approx process for each > client. I can reliably retrieve files from the cache without anything being logged at all. So even though your general argument makes sense, the premise is simply false. Given that the "cached" messages are not intended here, I am downgrading the severity as the remaining bits clearly are a request for additional features. Also note that munging together the data based on process ids is possible for a human, it makes it harder to write a log analysis software for approx that could gauge the effectiveness of the cache. Having a squid-like access log would make this far easier. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
