cache

[oberwetter]

I keep having a problem the following problem.
1. I have a vxml program on my hosted server.
2. I call plum and it executes the vxml program.
3. I change the vxml program and ftp the new version to the host (not plum).
4. I call plum and it still executes the old vxml program.
5. Is there some sort of caching going on with Plum?
6. I look at the call log and the link Click here to view saved VoiceXML script. And I see the old content.
7. When I edit and validate the vxml, I get the new content.
8. I'm checking with my hosting company where the vxml is to make sure they don't cache in scome way, but I'm pretty sure they don't, can't see why they would.
9. If Plum has a cache, is there any way I can force the cache to be flushed?

Any ideas or ways to isolate the problem would be appreciated.

Thanks

Robert

[support]

There is no way to force your start page to be instantly flushed from the cache on the IVR platform. There are, however, a couple ways to work around the cache. First, you can create a "prologue" page that, in turn, references your real start page with a <goto ... maxage="0"/> tag. This new page might get cached too, but it's really just a stub for your next page. Second, you can change your web server to respond to all document requests with headers that tell the requesting client not to cache the document. Third, instead of using a static file for your first page, you might consider using a dynamic script which your web server will likely flag as a page not to cache.

[oberwetter]

I tried your prologue suggestion without success. It still retrieved the old version from cache.

I also deleted the vxml file from the host and the application still worked. So Plum used the vxml from the cache without even going to the source to check the header.

Caching just doesn't seem to work correctly, or at least not as I would expect it to work. Any other suggestions?

How long does it take for Plum to expire the cache on its own?

Thanks.

[support]

On IVR systems, cache expiration is based on two possible numbers -- either the expiration time sent by your web server or the age of your file multiplied by 0.1. An expiration time sent by your web server will always override any other behavior. If the initial fetch of your start page had a high expiration time in it set by your server, it may very well be "stuck" until you clear it out with a prologue page. Can you post your prologue page here? The maxage attribute should have worked to empty the cache.

Also, deleting the IVR file itself will not help as the caching engine will not check the header until after the file has expired from the cache (this is standard HTTP-1.1 proxy behavior).

Standard practice for our professional services group is to always use a stub prologue page for the start page or to have a dynamically generated page (like a .asp or .php script) be the start page. Either situation guarantees complete control over caching behavior for us.