ezelkow1 opened a new issue, #9128: URL: https://github.com/apache/trafficserver/issues/9128
We have seen in production on some services a behavior change from 9.1 to 9.2. We are seeing instances of a cache reporting a TCP_IMS_MISS, yet every other indication in the transaction log appears that it came out of cache: `1664916002.027 chi=XXXXXX phn=XXXXX php=80 shn=- url=URL cqhm=GET cqhv=http/1.1 pssc=200 ttms=46 b=35332 sssc=000 sscl=0 cfsc=FIN pfsc=FIN crc=TCP_IMS_MISS phr=DIRECT pqsn=- uas="UAS" rr="""-""" cl="""35332""" cqhl=843 csscl=35332 cqssc=- cqssv=- ccc="""-""" occ="""-""" cocc="""max-age=1""" odate="""-""" cdate="""Tue, 04 Oct 2022 20:40:02 GMT""" olm="""-""" clm="""Tue, 04 Oct 2022 20:40:01 GMT""" oet="""-""" cet="""-""" opm="""-""" cpm="""-""" oex="""-""" cex="""-""" oce="""-""" cce="""-""" oct="""-""" cct="""application/dash+xml""" acc="""*/*""" ace="""gzip""" auth="""-""" ovar="""-""" cvar="""-""" ccvar="""-""" nhi=0 nhp=0 pcr="""-""" xrsn="""-""" stms=-1 ptms=0 ttfb=46 cmcd-request="""-""" cmcd-object="""-""" cmcd-status="""-""" cmcd-session="""-""" misc-psh="""-"""` I believe ATS did the "right" thing in this instance as it most likely had a properly updated object for the IMS request, though I cant be sure since I dont have the client header, and sent back a 200 with the object. However the crc=TCP_IMS_MISS is what is confusing and can mess with metrics since an IMS_MISS is stated as "The client issued an if-modified-since request and the object was either not in cache or was stale in cache. Traffic Server sent an if-modified-since request to the origin server and received the new object. Traffic Server sent the updated object to the client." when it definitely appears that ATS did not go to the origin in this instance The only way Ive been able to reproduce this so far is by using a parentage setup, caching the object, then blocking the origin, then issuing an IMS for that object. After timeouts finish it comes back with a 200, the object, and a sssc=0 and all indications it came out of cache. IMHO if this is what happened, some issue connecting to the origin, then it should be a TCP_REF_FAIL_HIT maybe? We dont have a TCP_IMS_FAIL_HIT crc. Though I also am not sure if this is the scenario we see in production as there are far more of these IMS_MISS's coming out of cache then comparable 9.1 boxes who return 502 for origin issues, which is what 9.1 does in the above testing scenario instead of pulling from cache. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
