Well, actually I am not sure whether is a wsgi problem or a webfaction problem.
Anyway I just observe TWO separated instances of cache.ram inside ONE web2py
instance. How could this be?
Detail description.
One of my web2py app's action is to refresh cache.ram and then log the result.
def cron_job():
session.forget() # otherwise session files will pile up
unnecessarily
cache.ram('foo', lambda: time_consuming_job(), time_expire=1800)
# following code borrowed from appadmin.py's ccache()
ram = { 'hits':0, 'misses':0 }
for key, value in cache.ram.storage.items():
if isinstance(value, dict):
ram['hits'] = value['hit_total'] -
value['misses']
ram['misses'] = value['misses']
status = 'hit:%d, miss:%d' % (ram['hits'], ram['misses'])
open('cron_job.log', 'a').write('... (%s), [%s]'% (...,
request.client, status))
And there is an external web2py cron running this trigger script:
import urllib
urllib.urlopen('http://localhost:54321/myapp/default/cron_job').read()
I setup web2py on webfaction days before. It is in wsgi mode, and I shrink the
working process from 2 to 1 (in order to use cache.ram supposedly). The default
apache2/conf/httpd.conf is very short and here is the important part (I think):
LoadModule rewrite_module modules/mod_rewrite.so
Listen 54321
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\" %D" combined
CustomLog /home/iceberg1975/logs/user/access_web2py_1_81_5.log combined
ServerLimit 1
WSGIScriptAlias /
/home/my_webfaction_account/webapps/web2py_1_81_5/web2py/wsgihandler.py
Everything seemingly works fine, until I surprisingly notice that, web2py uses
one cache.ram instance when being visited by a real-world request, but uses
another separated cache.ram instance when being visited by the localhost's cron
job.
Here is the apache log when being visited by a real-world request:
112.94.8.140 - - [03/Aug/2010:05:38:40 -0500] "GET /myapp/default/cron_job
HTTP/1.0" 200 15 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.125 Safari/533.4" 34391
And here is the apache log when being visited by local cron script, note that
there is no incoming IP:
- - - [03/Aug/2010:05:39:05 -0500] "GET /myapp/default/cron_job HTTP/1.0" 200
19 "-" "Python-urllib/1.17" 33972
Both generate similar log on web2py level:
127.0.0.1, 2010-08-03 05:38:40, GET, /myapp/default/cron_job, HTTP/1.0, 200,
0.033933
127.0.0.1, 2010-08-03 05:39:05, GET, /myapp/default/cron_job, HTTP/1.0, 200,
0.033501
But the cron_job.log reveals the difference, they are hitting different
cache.ram instance. How come?
Triggered at Tue Aug 3 05:38:40 2010, took 0.002 seconds. (112.94.8.140).
[hit:54, miss:64]
Triggered at Tue Aug 3 05:39:05 2010, took 0.002 seconds. (127.0.0.1).
[hit:20727, miss:702]
Oh yes, I guess one of the workaround/solution is to use cache.disk or
cache.memcache instead. But I am still curious to know what cause the above
"two cache.ram instances" problem even when I am running only one web2py
process. Or, do I?
[my_wf_acco...@web150 conf]$ ps -ef|grep 1_81
528 3529 1 0 Aug01 ? 00:00:00
/home/MY_WF_ACCOUNT/webapps/web2py_1_81_5/apache2/bin/httpd -f
/home/MY_WF_ACCOUNT/webapps/web2py_1_81_5/apache2/conf/httpd.conf -k start
528 3531 3529 0 Aug01 ? 00:01:37
/home/MY_WF_ACCOUNT/webapps/web2py_1_81_5/apache2/bin/httpd -f
/home/MY_WF_ACCOUNT/webapps/web2py_1_81_5/apache2/conf/httpd.conf -k start
Any feedback will be appreciated.
Sincerely,
Iceberg, 2010-Aug-03, 18:39(PM), Tue
