On 10/03/2016 2:17 a.m., Heiler Bemerguy wrote: > > Hi Amos, > > Now you can help me on tracking it down.. lol... can you? I don't know > what debug_options (apart of 88,3) I should enable. 88,9 to see what else is happening in and around that. I took a quick look and saw that 88,5 has details about what the followup action was. But there is something earlier which lead to that "0 bytes" situation. I am not familar what code paths are operation, so cant point straight at anything sorry. The 20,9 or 79,9 debug details might display it, but thats just a guess. > I just know that disabling range_offset will eliminate this issue, > because it won't even try to cache range requests. Also, it didn't > happen when I was using AUFS. > > Another examples: > 2016/03/09 00:27:54.016 kid2| 88,3| client_side_reply.cc(463) cacheHit: > clientCacheHit: http://au.download.windowsupdate.com/c/msdownload/upda > te/software/secu/2016/02/ie11-windows6.1-kb3139929-x64_55bffa59079eb8da45400d6b0432262f96adb3b0.psf, > 0 bytes > 2016/03/09 00:27:54.016 kid2| 88,3| client_side_reply.cc(470) cacheHit: > clientCacheHit: swapin failure for http://au.download.windowsupdate.co > m/c/msdownload/update/software/secu/2016/02/ie11-windows6.1-kb3139929-x64_55bffa59079eb8da45400d6b0432262f96adb3b0.psf > Nod. UFS/AUFS/diskd are designed for big objects. > > There are some 0 bytes responses (giving a swapin failure) that won't > give me much trouble because files are small, like this: > 2016/03/09 09:57:25.107 kid2| 88,3| client_side_reply.cc(463) cacheHit: > clientCacheHit: > http://www.mte.gov.br/images/Imagens/Noticias/2016/BRICS31.JPG, 0 bytes > 2016/03/09 09:57:25.107 kid2| 88,3| client_side_reply.cc(470) cacheHit: > clientCacheHit: swapin failure for > http://www.mte.gov.br/images/Imagens/Noticias/2016/BRICS31.JPG > > Looking the source code: > debugs(88, 3, "HIT object being deleted. Ignore the HIT."); > return; > } > > StoreEntry *e = http->storeEntry(); > > HttpRequest *r = http->request; > > debugs(88, 3, "clientCacheHit: " << http->uri << ", " << > result.length << " bytes"); > > if (http->storeEntry() == NULL) { > debugs(88, 3, "clientCacheHit: request aborted"); > > I don't get this "deleted", so the object is not being deleted, and > "request aborted" is not being show too.. The cache index entry that caused it to be a HIT is erased and any on-disk portion gets a RELEASE. The server gets cotacted to produce a correct copy, which might re-create those details if the object is (still) cacheable. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
