Inconsistent cache lookup

Comments

6 comments

  • Peter Wohlers

    Hi- If you look at your generated VCL from within the app, you will see the expanded #FASTLY hash macro shows the additional code of:

    ```

    -FASTLY HASH CODE WITH GENERATION FOR PURGE ALL

    #

    #if unspecified fall back to normal { set req.hash += req.url; set req.hash += req.http.host; set req.hash += "#####GENERATION#####"; return (hash); } #--FASTLY END HASH CODE ```

    So the below edits are most likely adding to the hash which already has req.http.host and `req.url``

    [quote="rayd, post:1, topic:305"] sub vcl_hash {

    call log_hash;

    set req.hash += req.http.Appcues-Original-Url; set req.hash += req.http.Appcues-Original-Host;

    FASTLY hash

    return (hash); } [/quote]

    Do you think this might be explaining the behavior you're seeing?

    0
    Comment actions Permalink
  • rayd

    Unfortunately I don't think that's it. Because I'm overwriting the entire vcl_hash function in my custom VCL and just including that #FASTLY hash macro (which just adds the generation part), I get this in my generated VCL:

    sub vcl_hash {
    
      call log_hash;
    
      set req.hash += req.http.Appcues-Original-Url;
      set req.hash += req.http.Appcues-Original-Host;
    
    #--FASTLY HASH start
      # support purge all
      set req.hash += "#####GENERATION#####";
    #--FASTLY HASH end
      return (hash);
    }
    

    I really think it's somehow related to the req.restarts > 0 but it doesn't seem like that should affect things. Unless the restart causes the hash to occur twice? Is that what you're suggesting?

    0
    Comment actions Permalink
  • Peter Wohlers

    OK. I don't think it would have anything to do with restarts. Do you have shielding enabled?

    This one might be hard to debug without going through the rest of your VCL.

    edit - yeah..sorry...see the shielding. would still like to see the vcl :smile:

    0
    Comment actions Permalink
  • Peter Wohlers

    and following up a bit...did you get a chance to look at this article? https://community.fastly.com/t/redirect-to-another-backend-based-on-response-status/51

    0
    Comment actions Permalink
  • Rogier Mulhuijzen

    Hi Ryad,

    What I think is getting in your way is that we disable clustering on restarts. Clustering is where one machine in a datacenter (cluster) is primary and one is secondary for any specific object and all the other nodes go there instead of your origin.

    Because restarts are often because of errors, and the error might have been in the clustering (we are reevaluating this), the clustering is disabled. You can, however, force the clustering if you create the Fastly-Force-Shield header. That should take care of making sure it is the primary or secondary that do the requests to origin, and make sure that your objects are cached for the whole cluster.

    Let us know how this goes.

    Cheers,

    Doc

    0
    Comment actions Permalink
  • rayd

    Hi Doc,

    We ended up changing our VCL completely and this ended up being a non-issue at that point (We decided not to cache the fallback content at all). But your explanation certainly seems to explain the behavior I was seeing. I think this would have fixed it. So for anyone else in a similar situation to me, take a look at Doc's answer above!

    Thanks a lot for your help!

    0
    Comment actions Permalink

Please sign in to leave a comment.