You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by GitBox <gi...@apache.org> on 2021/06/29 11:21:40 UTC

[GitHub] [trafficserver] VanillaHeaven opened a new issue #8011: The regex_invalidate API doesn't work when I added cache rules in cache.config

VanillaHeaven opened a new issue #8011:
URL: https://github.com/apache/trafficserver/issues/8011


   Hello.
   I tried to use the regex_invalidate API in [cache inspector utility](https://docs.trafficserver.apache.org/en/9.0.x/admin-guide/storage/index.en.html#using-the-cache-inspector-utility) to set a document invalid, but it seems doesn't work because I added the cache rule in cache.config.
   
   So is the priority of the cache rule in cache.config the highest? How can I make the regex_invalidate API take effect when I configure the caching rules in cache.config.
   
   The ATS version is 9.0.0, and the operating system I use is centos. The following is my test process:
   
   I added cache rules in cache.config as follows:
   `dest_domain=test.source.com   scheme=http  revalidate=2d`
   The default expiration time is two days for the documents whose host name is test.source.com.
   
   I initiated a request and got the response:
   ` curl "http://test.source.com/1M/2" -x 127.0.0.1:8089 -vo /dev/null
   ...
   < HTTP/1.1 200 OK
   < Server: ATS/9.0.0
   < Date: Tue, 29 Jun 2021 10:26:49 GMT
   < Content-Type: application/octet-stream
   < Content-Length: 1048576
   < Last-Modified: Fri, 16 Apr 2021 13:11:12 GMT
   < ETag: "60798cf0-100000"
   < Accept-Ranges: bytes
   < Age: 0
   < Proxy-Connection: keep-alive`
   
   And I get the hit status which is hit-fresh from the log and the response header X-Cache.
   `curl "http://test.source.com/1M/2" -x 127.0.0.1:8089 -vo /dev/null -H "X-Debug: X-Cache"
   ...
   < HTTP/1.1 200 OK
   < Server: ATS/9.0.0
   < Date: Tue, 29 Jun 2021 10:53:39 GMT
   < Content-Type: application/octet-stream
   < Content-Length: 1048576
   < Last-Modified: Fri, 16 Apr 2021 13:11:12 GMT
   < ETag: "60798cf0-100000"
   < Accept-Ranges: bytes
   < Age: 4
   < Proxy-Connection: keep-alive
   < X-Cache: hit-fresh
   <
   { [data not shown]
   100 1024k  100 1024k    0     0   169M      0 --:--:-- --:--:-- --:--:--  200M`
   
   According to the official documentation, I tried to use the regex_invalidate API in [cache inspector utility](https://docs.trafficserver.apache.org/en/9.0.x/admin-guide/storage/index.en.html#using-the-cache-inspector-utility) to set the document invalid, and the result of the web page response shows that the operation has been successful.
   ![image](https://user-images.githubusercontent.com/32634416/123786225-07492080-d90c-11eb-8e3a-8362ab6d84c5.png)
   But when I made the request again, the response result shows that the cache is still hit.
   ` curl "http://test.source.com/1M/2" -x 127.0.0.1:8089 -vo /dev/null -H "X-Debug: X-Cache"
   ...
   < HTTP/1.1 200 OK
   < Server: ATS/9.0.0
   < Date: Tue, 29 Jun 2021 10:26:49 GMT
   < Content-Type: application/octet-stream
   < Content-Length: 1048576
   < Last-Modified: Fri, 16 Apr 2021 13:11:12 GMT
   < ETag: "60798cf0-100000"
   < Accept-Ranges: bytes
   < Age: 172
   < Proxy-Connection: keep-alive
   < X-Cache: hit-fresh
   <
   { [data not shown]
   100 1024k  100 1024k    0     0   138M      0 --:--:-- --:--:-- --:--:--  166M`
   
   I checked the debug log, and it showed that the expiration time of the document is based on the caching rules configured in cache.config, so that the regex_invalidate API doesn't work.
   `[Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:438 (calculate_document_age)> (http_age) [calculate_document_age] age_value:              0
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:439 (calculate_document_age)> (http_age) [calculate_document_age] date_value:             1624962409
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:440 (calculate_document_age)> (http_age) [calculate_document_age] response_time:          1624962409
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:441 (calculate_document_age)> (http_age) [calculate_document_age] now:                    1624962581
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:442 (calculate_document_age)> (http_age) [calculate_document_age] now (fixed):            1624962581
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:443 (calculate_document_age)> (http_age) [calculate_document_age] apparent_age:           0
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:444 (calculate_document_age)> (http_age) [calculate_document_age] corrected_received_age: 0
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:445 (calculate_document_age)> (http_age) [calculate_document_age] response_delay:         0
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:446 (calculate_document_age)> (http_age) [calculate_document_age] corrected_initial_age:  0
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:447 (calculate_document_age)> (http_age) [calculate_document_age] resident_time:          172
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransactHeaders.cc:448 (calculate_document_age)> (http_age) [calculate_document_age] current_age:            172
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7408 (what_is_document_freshness)> (http_match) [10] [what_is_document_freshness] fresh_limit:  86400  current_age: 172
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7455 (what_is_document_freshness)> (http_match) [10] [..._document_freshness] initial age limit: 86400
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7508 (what_is_document_freshness)> (http_match) [10] [..._document_freshness] revalidate_after set, age limit: 172800
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7511 (what_is_document_freshness)> (http_match) [10] document_freshness --- current_age = 172
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7512 (what_is_document_freshness)> (http_match) [10] document_freshness --- age_limit   = 172800
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7513 (what_is_document_freshness)> (http_match) [10] document_freshness --- fresh_limit = 86400
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7514 (what_is_document_freshness)> (http_seq) [10] document_freshness --- current_age = 172
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7515 (what_is_document_freshness)> (http_seq) [10] document_freshness --- age_limit   = 172800
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7516 (what_is_document_freshness)> (http_seq) [10] document_freshness --- fresh_limit = 86400
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:7535 (what_is_document_freshness)> (http_match) [10] [..._document_freshness] document is fresh; returning FRESHNESS_FRESH
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:2557 (HandleCacheOpenReadHitFreshness)> (http_seq) [10] [HttpTransact::HandleCacheOpenReadHitFreshness] Fresh copy
   [Jun 29 18:29:41.104] [ET_NET 23] DEBUG: <HttpTransact.cc:2653 (need_to_revalidate)> (http_seq) [10] [HttpTransact::HandleCacheOpenReadHit] Authentication not needed`
   


-- 
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: issues-unsubscribe@trafficserver.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org