Closed (duplicate)
Project:
Memcache API and Integration
Version:
6.x-1.9
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
10 Apr 2012 at 09:59 UTC
Updated:
8 Mar 2013 at 14:16 UTC
Jump to comment: Most recent
Comments
Comment #1
michiellucas commentedI have the same issue, looking for a way to exclude ajax paths from memcache.
Did you succeed?
Comment #2
edu2004eu commentedAm having the same issue with AJAX login in D7 with Memcache 7.x-0.0. I've traced it down to this line (somewhere in the drupal core):
This is returning nothing. The code is located in:
includes/ajax.inc -- around line 315
Comment #3
evete commentedWe run into similar error with memcache, the user autocomplete and the location province autocomplete stop working. When disable memcache module, everything works. The "cache_form" in our settings.php is correctly set to "database".
As edu2004eu suggested, seems the two required path, in our case, user/autocomplete and the /location/autocomplete/* are not set correctly.
We use the current 6.10 release.
Comment #4
edu2004eu commentedHere's what I did to fix this, it might help someone.
Your sites/default/settings.php should look something like this:
Or at least something similar. What I did, was to comment out the line saying: 'cache_form' => 'default',
So the result was:
It seems that some forms were badly cached in Memcache and they couldn't be retrieved (in your cases the comment form).
Comment #5
robloachThe issue is that Memcache statistics are being output with the AJAX request. Disabling the statistics output should fix the AJAX requests. Bug in Memcache module, which forces output of the statistics on every request, rather than just on HTML requests.
Comment #6
Martin Klinkigt commentedHi
may I also vote for this bug. Currently this bug stops me from using this module. maybe I can give some debug information. Basically this module seems to work also for forms of all kind including ajax.
However, I have observed that the module stops working after some time which means forms are not processed anymore. I have check the cache_form table and it contains about 700 entries. I think this normal for a small site with some active users. I suppose this is not the problem. More dramatic is the fact that drupal stops adding the form build id into the database. Without a build id nearly everything will stop working since drupal will detect it as a xss attack.
restating the webserver or the database does not solve the issue. Only after restarting the whole server the website worked again for a while. I did not check whether restarting the memcached daemon helps.
I am using latest version 7.x-1.0 from January 19.
edit:
Some more info. I am running Ubuntu 12.10 in an VPS and followed the explanation from this site: https://www.digitalocean.com/community/articles/how-to-install-and-use-m...
edit 2 (maybe solved):
I maybe found my problem. It was due to incomplete documentation here: http://drupal.org/node/1131468
I check now the README.txt more carefully and found the following:
I would recommend to update the documentation on the page above.
Thank you for your time and I apologize for causing trouble.
best
Comment #7
erikwebb commentedYou do not need to "enable" the use the cache backend. The point made in #5 is that the module itself could use a bug fix to remove this problem, but the cache backend itself should be unaffected.
Do the problems go away with the module disabled, but the cache backend still in use?
Comment #8
erikwebb commentedSome work is started over here - #1909398: Don't output statistics on AJAX requests
Comment #9
ajlozier commentedThank you Martin. Your solution worked for us, something that had been confounding us for weeks!
Comment #10
gauravktomar commentedThanks Dude! It really helped me!!