I have been having this issue with one of my clients for quite a while and managed to track down the issue.

What was happening was that because we use features to enable better configuration control we have a large number of default views and working with memcache which will arbitrarily delete cache objects from memory. If the cache object was not the default view index then it would have a blank view in the cached array and the system would then assume that the default view has been deleted, and other things like block settings would also stop working.

Because of the way that this cache is built to begin with there is actually no way to rebuild a single default view on the fly, so my patch changes views behavior to abort the loading of the default views when one has been lost and work through the entire build process of the loading of the default views back into memory and recaching them.

Looking at my logs I am also wondering if locking should be put around this build process as I have 3 or 4 people rebuilding this at the same time when the rebuild is happening.

The patch is to 6.x-2.x-dev but should be able to be cherry-picked to 6.x-3.x-dev with no problem.

CommentFileSizeAuthor
0001-Fix-issue-with-default-views-being-lost.patch1.08 KBgordon

Comments

dawehner’s picture

dawehner
Primary language German
commented

Linking a very related issue #853864: views_get_default_view() - race conditions and memory usage which tries to fix a lot of problem for php5, maybe just try it out.

gordon’s picture

gordon commented

I have taken a look at it, and I am not 100% sure that #853864: views_get_default_view() - race conditions and memory usage solves this issue. It seems like quite a overly complicated patch.

I am not sure why it is not using Drupal's built in locking which will work for both php4 and 5.

mgriego’s picture

mgriego commented

I've been running into this exact issue on our site. The views will get corrupt in the (memcache) cache. I didn't realize what was happening was that memcached might be evicting single cached view objects. I liked the look of that patch enough that I went ahead an put it in place on our production site yesterday. The preliminary results look very good. The logging has helped to show just how much this was actually happening. I realize this probably isn't the end-all-be-all patch (I agree with the locking comment), and I've followed the other referenced bug as well. This patch, though, was very simple to put in, and it does *seem* to be dealing with our immediate problem. We're going to keep an eye on it, of course, but definitely thanks for that patch.

dawehner’s picture

dawehner
Primary language German
commented
Status: Needs review » Needs work

In general i'm really really careful with changing anything in 6.x-2.x as it's a stable version, which just get's critical bug fixes,
but sure this corrupted default views are horrible. Do you have any clue why this happens for example on memcache?

One thing i realize here is that if one view can't be stored, for whatever reason, all default views are rebuilt, even most of them are ok. Sure this is no way to just rebuilt a certain default view, as there is no information where a certain one is stored in the disk.

Locking seems to be a good idea, this forces all people to update to recent 6.x versions of core, hey!

+++ b/includes/cache.incundefined
@@ -109,10 +109,17 @@ function _views_discover_default_views() {
+    ¶

Be sure not to include unneeded whitespace.

gordon’s picture

gordon commented

There is 2 reasons why you can't rebuild just the just one view which is missing.

The first is that when loading the view you could actually get many views not just one. So reloading just one view you would need to expand the index to include which module it came from and then load in just that modules default views and then you may get many views, which would all need altering.

drupal_alter('views_default_views', $cache);

This alter requires all of the views to be past on you can't pass just 1 at a time, and passing the views more than once will cause issues depending on the implementation of the hook.

Also since this was in the stable branch, I wanted to make as few changes as possible so that there was as little possibility for new bugs to be introduced. Basically keeping the changes as simple as possible.

mgriego’s picture

mgriego commented

To answer the question about memcache, memcache can (and will) expire items in its cache outside the control of the application. The problem is that Views wasn't taking this into account, so it expected that all items would still be cached together. This would be true for the database cache, as that's totally under Drupal's control as to when items expire. For memcache, though, memcache may expire an object if it needs to make room for something else (or if the object is set to expire). If one view cache entry expires, but the index is still intact, then Views will get incorrect information from the cache subsystem, because it's assuming that all cache items *should* be there when they *may not*.

And, FYI, I'm actually using this patch on Views 6.x-3.0. We could bump the version number on this since the same problem exists there if others agree...

mustanggb’s picture

mustanggb commented
Issue summary: View changes
Status: Needs work » Closed (won't fix)