1196: Statistics are not available for this backend

markb*****@gmai***** (Google Code) (Is this you? Claim this profile.)
chipx86
chipx86
Oct. 13, 2009
What version are you running?
1.0

What's the URL of the page containing the problem?
http://servername/admin/cache/

What steps will reproduce the problem?
1. click on "Server Cache" link on administration dashboard

What is the expected output? What do you see instead?
I would expect to see cache information.  instead i see:
Server Cache
Cache backend: django.core.cache.backends.memcached 
Statistics
Statistics are not available for this backend.

What operating system are you using? What browser?
Gentoo 2.6.27-r7

Please provide any additional information below.
Perhaps i am misconfigured?

/etc/conf.d/memcached
LISTENON="127.0.0.1"

settings_local.py
CACHE_BACKEND = 'memcached://localhost:11211/'
#1 djs%n-c*******@gtempacc******** (Google Code) (Is this you? Claim this profile.)
I see this problem too. I'm positive that I've seen it work at one point. I am
wondering if the trailing slash is the problem. If you look in admin/cache_stats.py,
the host is matched with:

   m = re.match("memcached://([.\w]+:\d+;?)", settings.CACHE_BACKEND)

which wouldn't match with a trailing slash. I tried removing the trailing slash from
my config but I still didn't get any stats. I'll have to try debugging it further.
chipx86
#2 chipx86
Should be an easy fix.
  • +Confirmed
  • +Milestone-Release1.0.x
chipx86
#3 chipx86
Fixed on release-1.0.x in rd6739aa.
  • -Confirmed
    +Fixed
  • +Component-Admin
  • +chipx86
#4 markb*****@gmai***** (Google Code) (Is this you? Claim this profile.)
I still get the same error message after upgrading to 1.0.4:

Server Cache
Cache backend: django.core.cache.backends.memcached 
Statistics
Statistics are not available for this backend.
chipx86
#5 chipx86
We use Django's own function for determining if the backend is valid. I've tested it
on your exact server string... So I don't understand why you'd be seeing this fail.

This can also happen if we can't query anything from the particular memcached server.
We have to send it a command and if it doesn't succeed, we can't query the information.
  • -Fixed
    +NeedInfo
chipx86
#6 chipx86
Are you using python-memcached or cmemcached?

What version of memcached are you running? What version of Python?

What happens if you telnet to localhost:11211 and, at the prompt, type: stats
chipx86
#7 chipx86
We can continue discussion on here, though at this point it's an issue with your
setup or components. The core bug (failing to match the memcached string) is fixed.
  • -NeedInfo
    +Fixed
#8 lon***@gmai***** (Google Code) (Is this you? Claim this profile.)
I agree it's a different issue, so maybe it's not the right place to discuss it

I see it too with 1.4.  I added a variable in reviewboard/settings.py

# Load local settings.  This can override anything in here, but at the very
# least it needs to define database connectivity.
try:
    import settings_local
    from settings_local import *
except ImportError:
    dependency_error('Unable to read settings_local.py.')

LN_CACHE_BACKEND = CACHE_BACKEND
TEMPLATE_DEBUG = DEBUG


And when I try to print it in reviewboard/admin/views.py

    logging.debug(settings.CACHE_BACKEND)
    logging.debug("=====")
    logging.debug(settings.LN_CACHE_BACKEND)

This is what I got:

2009-10-19 16:59:24,116 - DEBUG - file:///tmp/reviewboard_cache
2009-10-19 16:59:24,116 - DEBUG - =====
2009-10-19 16:59:24,116 - DEBUG - memcached://127.0.0.1:11211/


So clearly settings.CACHE_BACKEND has been modifed in the meantime, but I cannot find
where.
#9 lon***@gmai***** (Google Code) (Is this you? Claim this profile.)
I found a discrepancy between settings_local.py and the siteconfig_siteconfiguration table in MySQL.  The 
table had the file:///tmp/reviewboard_cache entry, but it did not prevent memcached from being in use.

I believed the discrepancy is because I first installed Review Board without memcached, and then reinstalled it 
with memcached.  I did not delete the tables, and rb-site does not check for that.  I had an error because 
admin was already defined, but I bypassed the issue by using admin2.

After fixing the table, I can see the cache statistics :)
#10 markb*****@gmai***** (Google Code) (Is this you? Claim this profile.)
Realized that i have both installed:

net-misc/memcached-1.4.1
dev-python/python-memcached-1.40
dev-lang/python-2.5.4-r2

reviewboard ~ # telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
stats
STAT pid 2263
STAT uptime 1206023
STAT time 1256047646
STAT version 1.4.1
STAT pointer_size 32
STAT rusage_user 6.524407
STAT rusage_system 17.825114
STAT curr_connections 5
STAT total_connections 11595
STAT connection_structures 8
STAT cmd_get 14386
STAT cmd_set 1217
STAT cmd_flush 0
STAT get_hits 2104
STAT get_misses 12282
STAT delete_misses 0
STAT delete_hits 0
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT bytes_read 35665771
STAT bytes_written 65854408
STAT limit_maxbytes 134217728
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 5
STAT conn_yields 0
STAT bytes 34614404
STAT curr_items 1213
STAT total_items 1217
STAT evictions 0
END
#11 markb*****@gmai***** (Google Code) (Is this you? Claim this profile.)
from the above posts by lonico, i see the siteconfig_siteconfiguration table has
"cache_backend": "locmem:///" - is that the problem with my setup?
#12 markb*****@gmai***** (Google Code) (Is this you? Claim this profile.)
So i tried changing the siteconfig_siteconfiguration table as follows and it works. 
sweet.
OLD:  "cache_backend": "locmem:///"
NEW:  "cache_backend": "memcached://127.0.0.1:11211/"

results (after restarting apache and memcached):
Server Cache
Cache backend: django.core.cache.backends.memcached 
Statistics
127.0.0.1:11211 Memory usage: 2.9 KB 
Keys in cache: 1 of 1 
Cache hits: 0 of 4: 0% 
Cache misses: 4 of 4: 100% 
Cache evictions: 0 
Cache traffic: 3.2 KB in, 759 bytes out 
Uptime: 41 
#13 rro****@gmai***** (Google Code) (Is this you? Claim this profile.)
I've been using ReviewBoard for awhile and bugs like this pop up because of
inconsistencies between what you THINK you have as a setting (based on
settings_local.py) and what's in siteconfig_siteconfiguration.

I recommend simplifyng ReviewBoard by removing the siteconfig_siteconfiguration
module. It's complex and heavy weight. Just read all settings from settings.py files
and make people who know Django "by the book" happy.
chipx86
#14 chipx86
Some things should be removed, yes, but we will not be going to a pure settings.py
solution for configuration. When we moved away from this, it simplified things for
the majority of our users quite a lot. Sure, there are some settings that are broken,
and we'll fix those, but let's not throw out the baby with the bath water now.

We're not targetting experts who know Django in and out. We're targetting companies
and projects who may or may not know Django, who want to use Review Board as a tool.
There's a difference between a webapp provided as a complete solution for end users,
and a module for use with Django or for developers to integrate into a project.