Cache incorrectly serving old content under specific conditions

Comments

4 comments

  • Hiro

    [quote="AMDmi3, post:1, topic:1249"] 2640410 [/quote]

    Hi Dmitry,

    Thanks for reaching out. It seems TTL( beresp.ttl ) is currently set longer than 30 days for this URL. So it is possible to get the 30 days old object from the edge POP, and you might need to reach out to them to see why they'd like to serve the long TTL cache.

    As far as I see, the different edge nodes have the different age objects at this moment and some of them have a different Content-Length. However, I don't see anything specifically outstanding that hints the different cache nodes are sending different objects in the VCL. If this is not expected and they'd like to submit a ticket for us, we are more than happy to assist to sort this out.

    Please let us know if you have any further question. Thank you, Hiro | Fastly Support

    0
    Comment actions Permalink
  • AMDmi3

    The moments when the cdn server the fresh file can be seen on this graph:

    https://repology.org/graph/repo/pkgsrccurrent/metapackagestotal.svg

    as spikes (newer file->more data).

    0
    Comment actions Permalink
  • Steven Chuob

    @AMDmi3 for the TTL we keep the object in the cache for as long as we can base on the rules a customer set either by using Cache-Control or VCL (Varnish Configuration Language) on a specific service. So to grab a new fresh object, it would require a user to request the object again after it expires. Or the object has some sort of ETAG or if modified since headers.

    I recommend opening a ticket with us and/or NetBSD, there might be something in their VCL that could be changed to ensure you get the latest object. I think the communication and tracking over a ticket would be more beneficial for this issue than a community post.

    Thanks, Steven

    0
    Comment actions Permalink
  • AMDmi3

    Thank you, I've written NetBSD guys.

    0
    Comment actions Permalink

Please sign in to leave a comment.