[Plugin: W3 Total Cache] CDN Offloading Works Initially; Stops Working by Next Day

Have the same issue, i enabled “Force over-writing of existing files” and exported everything again, it started to work as normal, a couple of days later when i checked it was being served locally again.

Also looking for a solution to be able to serve slideshow images from the CDN.

mjmcgowan: Are you using CloudFront or a different CDN?

I have the same issue with CloudFront.

yes im using cloudfront

I installed W3 Cache 2 days ago and see it behaving the same way. If I deactivate the plugin then reactive, it starts serving the CDN content from Cloudfront.

It seems to only be the JS and CSS minify and *Other files like from NextGen Gallery that stop being called from the CDN, all normal media like blog images are still being called from the CDN.

I can also open a different browser on the same machine and get the CDN calls to work, then go to a blog post and the same calls are now being called locally, not from the CDN.

Something is not right for sure.

Has anyone checked their unsuccessful transfer queue to make sure it’s empty when problems arise?

As I said in the OP, there are many entries in the Unsuccessful File Transfer Queue, but they all say “Object already exists”.

I can also add, as I have also mentioned in this as-yet unanswered post, that the transfer queue fills up with plenty of “Object already exists” errors. Deleting the queue helps, but the problem comes back.

An expensive workaround is to turn on the “Force overwriting” option. When selected, the CDN keeps on working as expected, but at the cost, for my small blog, of an additional 20,000-50,000 uploads to S3 a day, for files which have not changed at all. Amazon, of course, charges for all of those dearly.

Could it be that somehow W3 Total Cache thinks it needs to upload files which have not been changed at all, even in their cached state?

I had a bunch of files in my cue yesterday when checking this post and had removed them from the que… they were all File Already exists errors. They are back in the que now.

It seems W3 Total Cache by W3 EDGE doesn’t detect the images files both when I set to automatically Import external media library attachments and when I import media library attachments (images) to CDN. Now I have to copy all the files to cdn manually. Please help me to solve the problem. Thanks

ruditrg: Did it work at any point?

If it worked initially but then stopped working after some time, then let us know any patterns you’ve seen in which files work and which fail. Also let us know what error messages you’ve seen in the Unsuccessful File Transfer Queue (although everybody seems to be having the same experience: all entries say “Object already exists”.

If however uploading files to the CDN via the plugin has never worked, then please start a new forum topic. This topic is specifically on the issue of functioning W3TC CDN setups that inexplicably fail after some time.

The problem just appeared yesterday, 1st Feb. Upload queue is empty (No Unsuccessful file transfer queue) and I got no error message, just uploading files to the CDN via the plugin not worked.

I’ve been checking settings to help see if something pops up that can clarify what is happening.

I do know in the CDN setup when I was installing W3 that I get an ERROR when trying the test upload. I figured I was stuck when I installed but went ahead and did all the manual uploads of initial media, minify etc, and it worked.

Maybe this test failure reflects something. Can you guys check yours and see.

This happens on Auto, SSL and non SSL in the options for connecting to Cloudfront.

In my case, there were no errors on set-up, and the Test Upload worked fine. I have even deleted all the files of the plug-in, and I have reinstalled it, from scratch, resetting all settings.

The CDN works at first (except for a few files it always misses, which I think is a bug, which I described here, but which I cannot figure out a way to report as a bug yet).

After an hour or a few, however, the files are no longer being served from CDN, progressively fewer and fewer get served, eventually only the favicon seems to come from the CDN. The “Upload queue” fills with errors “Object already exists”. Clearing the queue seems to fix the problem temporarily. The only permanent workaround I found was to “Force overwriting” but it is costly as it generates 10k-20k extra S3 uploads of entirely unchanged files at least, and even 70k on some days.

I am wondering if this is specific to S3/CloudFront or also an issue with Rackspace. I might move to Rackspace for a test run, has anybody who had this issue with CloudFront tried Rackspace yet?

I am prepared to do more testing or answer other questions to help resolve this bug.

I mostly ditto your experiences:
* Test CloudFront Upload always works fine.
* I removed and reinstalled the plugin from scratch. I *think* that wasn’t effective.
* What did do the trick was creating a new S3 bucket and CF distribution and repopulating it.
* I’ve cleared the Upload queue, checked “Force over-writing of existing files”, and manually initiated a re-upload via the “exporting media library to CDN”, “Upload includes files”, and “Upload theme files” buttons. That seems to have done the trick for 90% of the files. (NOTE: “Upload minify files” always shows 0 files. Is this a related problem?)

My config: (should I post my w3-total-cache-config.php file? [other than passwords, obviously])
Running on an EC2 instance using EBS storage.
* General Settings:
** All cache types are enabled. Everything is set to APC, except the CDN is CF.
** Enable file locking: I’ve tried both ways. Currently unchecked.
* CDN Settings:
** General: All six items are checked.
** Advanced:
*** Enable changed files auto-upload: checked
*** Auto upload interval: I had experimented with lower values (600), but restored to its original value of 3600.
*** Re-transfer cycle interval: ditto. currently back to 900.
*** Re-transfer cycle limit: 25
*** filetypes: Appended “;*.pdf” to all three fields
*** never touched the rest.

Frederick and team: Please let us know what further info would be helpful in resolving this.