The caching period is up the the client, technically. So when we're doing template work, for instance, we'll put in a request to turn off caching altogether on our Test site. But I'm not sure what might be causing your TNEW server to keep "whitelabeling" your site. Is it possible that the template server is treating the TNEW servers differently (i.e. firewall rules, particularly adaptive firewalls) to the systems you check it from?
Not in any way I can think of. I maintain the www site and I've put nothing in place that would single out TNEW servers for any reason. Assuming it's an HTTPS request like any other, there shouldn't be anything blocking them. And again, curious why it wouldn't degrade to a cached copy rather than to whitelabel. If that's not a feature, I'd think it's a no-brainer enhancement request.
I didn't know turning off caching for development was an option, that's interesting. Thanks!
I'd definitely put in a support ticket. They may have an answer or be able to see something in their logs.
I do have an open ticket. Just putting this out there for more insight. Thanks!
It's definitely the case that if the template location is requested and failed, the site will degrade to the white-label design. I actually prefer this because it allows me to control putting my test site into white-label mode on purpose for testing.
You SHOULD be able to find error messages in the TNEW logs whenever the template location fails, and this will include the location that was attempted. In my experience, sometimes this actual location can be "out of sync" with what is listed in the TNEW admin page "Configuration Information" section. If that's the case, support can sort you out.
Thanks, Nick. Whatever support is finding in the logs seems to be unhelpful, but maybe if we keep seeing it over time, we can narrow down what's happening.As far as the site degrading to white-label for a missing template, I can certainly see the value in that behavior on the Test site or as a "dev mode" feature. For a production site it seems absurd to me, frankly, and highly undesirable.
Plus, if that's the case, why is the template even cached at all? Unless you're telling me that TNEW both caches the template and checks for its existence/availability? Like it only uses the cached template if it finds the template file exists at the remote URI? Because if I make a change to my template, I have to clear the cache in order to see it, so it's clearly being cached. This would mean that the application is designed to do basically this:1. Get the remotely-hosted template2. Cache the template to help performance3. Check for the existence of the remotely-hosted template ON EVERY PAGE LOAD and4. ONLY if that check returns true, still use the cached version5. Otherwise default to white-labelThat's a very specific choice, and I'd be interested in the developers' reasoning behind it, particularly for the production site. (And I know you're not a developer at the network, just musing here.)
Hi Christian,
Here is how the template caching with TNEW works - both live and test work the same.
Each site has a properties file that is managed by support (at some point parts of this, including template management, will be exposed for self-management - no timeline but it's something to keep an eye out for)
In that properties file there is a property for how long the TNEW site should cache the hosted template. It can be 0 or greater.
Lets say that it's set to 10 minute.
On Startup, TNEW reaches out and gets the template from the origin you specify on your web servers and puts it in the template cache.
Every 10 minutes, TNEW will attempt to gather a fresh version of the template. It does not check the origin again on any requests during that 10 minute period.
If, upon attempting to retrieve the fresh version of the template, it is found and successful, the version of the template in the cache is replaced with a fresh copy and served to the user.
If retrieval fails, and there is still an existing copy of the template in the cache, then TNEW will serve the cached copy of the template for the next 10 minute period, at which time it will re-try. TNEW will continue to server the old cached version until one of two things happens:
1. A fresh copy is succesfully retrieved, and can replace the existing cache copy
2. The TNEW host cache is cleared, or app pool is recycled thus clearing the host cache for the template. If this occurs, and at application startup TNEW is still not able to retrieve the template, it fails over to white label mode, since it has no version of the template in cache, and it is unable to retrieve the template from your origin.
I see your ticket and will update it with this information so that support can try to sort out why communication breaks down between your TNEW host and the template.
Christian Bisgard can you confirm if this is continuing to happen?
You can have different cache time settings in test and live for your template.
Thanks,
Chris
Hi Chris Szalaj,
Thank you so much for taking the time to outline the process. This is a big relief, because what you are describing is pretty much the ideal behavior in my opinion, and exactly what I hoped.
Since our TNEW host has lost the template a few times now, I'm trying to figure out where in the process there may have been a breakdown. Maybe support will have some ideas.
I am not sure if this is continuing to happen, since it's hard to catch it in the moment. It's been reported to me three times, two of which I was able to reproduce within a few minutes of being informed. Clearing the TNEW cache manually resolved it in both those cases. The third resolved itself.
Thanks again, Chris -- really appreciate the reassuring explanation.
No problem Christian Bisgard
Something that may give us a clue is the web server logs on your end -- IIS, Apache or NGINX request logs for the host that serves your template. You should see a request for the template at least 2x within a 10 minute period, one for each host in your TNEW production array, and then if TEST is pointed at the same location, you'd see requests for that too. It would help us figure out if the request is even making it to your web hosts, or, if it is, what the error is from the origin.
Next time if it happens, check your request logs right away and see if there is an error we can use.
Thanks, support should pick it up with you from here.