1196: Statistics are not available for this backend
- Fixed
- Review Board
markb*****@gmai***** (Google Code) (Is this you? Claim this profile.) | |
|
|
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/'
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.
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.
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
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
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
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.
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 :)
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
from the above posts by lonico, i see the siteconfig_siteconfiguration table has "cache_backend": "locmem:///" - is that the problem with my setup?
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
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.
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.