After upgrade to 3.5 only views with caching set to 'None' work - Time based caching gives "Page not found" errors

Are you use you have updated to 3.5 or just to 3.4?
In general there have been an issue in 3.4, so this is somehow a critical information.

Please also show us one of your views, to be able to figure maybe something out
what is going on.

I am also having problems with cached views in 3.5. I get an error like the following:

Additional uncaught exception thrown while handling exception.
Original

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT alias FROM {url_alias} WHERE source = :source AND language IN (:language, :language_none) ORDER BY language ASC, pid DESC; Array ( [:source] => node/1938 [:language] => en [:language_none] => und ) in drupal_lookup_path() (line 150 of /path/to/drupal/includes/path.inc).
Additional

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => php [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:291:"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT alias FROM {url_alias} WHERE source = :source AND language IN (:language, :language_none) ORDER BY language ASC, pid DESC; Array ( [:source] => node/1938 [:language] => en [:language_none] => und ) ";s:9:"%function";s:20:"drupal_lookup_path()";s:5:"%file";s:47:"/path/to/drupal/includes/path.inc";s:5:"%line";i:150;s:14:"severity_level";i:3;} [:db_insert_placeholder_4] => 3 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => https://mysite.com/myview [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => 128.95.248.6 [:db_insert_placeholder_9] => 1347379290 ) in dblog_watchdog() (line 154 of /path/to/drupal/modules/dblog/dblog.module).

I wonder if this is a duplicate of #1748526: 7.x-3.5 upgrade affecting some Views with time-based cache enabled? One of the posters identified a problem with the way taxonomy arguments are passed (comments #16 and #17), but I'm confused about which versions and patches he's working with.

Also, I noticed it makes a difference on some views whether I include all the arguments in the path or leave some out and expect it to return all results. Some work when I provide all the arguments.

I have not been able to solve this problem on one set of sites, however they are some dev sites and it is possible other modules/factors are coming into play. I originally upgraded to 3.4, and then to 3.5 when it became available.

Another set of sites I upgraded directly from 3.3 to 3.5, and did not experience any problems (keeping fingers crossed). Will leave this issue as active since I didn't originally report the problem.

I'm very familiar with this issue, after two days of problems related to this upon upgrade from 3.3 to 3.4, then fixed with 3.5. This should not be a problem for people using 3.5 if the upgrade was correctly processed. At least, we are not seeing issue reports of any frequency related to it, so I am closing.

I am having this issue, and there are plenty of followers as well.

giorgio79, you and the other 7 followers may be some of the few. This was a HUGE problem upon upgrade from 3.3 to 3.4, but the immediate release of Views 3.5 a couple of days later reverted the patch that had been causing the problem. For most of us, 3.5 resolved the problem and caching works fine.

More documentation (23 comments and several patches) on this same problem may be found here, which I've closed as a duplicate: 7.x-3.5 upgrade affecting some Views with time-based cache enabled

Here is the issue that originally caused the failure, which was implemented in 3.4 and reverted back with the 3.5 release: cache_get performance significantly worse in D7 (D6 -> D7 regression)

giorgio79, I noticed from the other issue that you are using Search API Views. Do you think that module is creating problems with caching for your individual situation upon upgrade to Views 7.x-3.5?

Thanks couturier, time based caching is giving me 404s on simple Views and Search API Views as well even after an upgrade to 3.5. I will set this back as closed, and try to reassess the issue with some accurate description, and open a new issue.

My guess is that other modules or the View configuration settings (taxonomy filters or arguments, etc.) may be interfering with 3.5 caching (heatherwoz also wonders this, see #4, above). Have you double-checked the filter and argument settings to make sure that nothing was unset by the upgrades? A lot of people had the boolean operator settings in Views filters unset upon upgrade to 3.4. So, unless you went directly from 3.3 to 3.5, that could have affected you. Also, I and others are experiencing some issues with the interactions of multiple filters during the latest upgrades. One issue even resolves when sort criteria is disabled, so you may want to test several variations of your View to see if other settings are also interacting with the caching.

High level Drupal developers in my local user's group tell me that they do not use Views caching at all. Rather, they approach it on the server side (Varnish is something I often hear them mention). That's not an option for people who don't have server access.

As heatherwoz mentioned, her only caching problems in 3.5 are on dev sites where she has extra modules installed that are not on her production sites. So, you might try disabling modules that may be suspect and seeing if you can identify if one of those is clashing with Views 7.x-3.5. Maybe heatherwoz would give you a list of her production modules vs. dev modules to compare where the most likely modules for the interference might be. I hope you can find a solution.