It depends on how apache is configured. If you are serving two
different ports it is possible it is creating two processes. In this
case you have one cache.ram per process.
On Aug 3, 11:19 am, Iceberg <iceb...@21cn.com> wrote:
> On Aug 3, 7:39 pm, iceb...@21cn.com wrote:
>
>
>
> > 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
>
> Mmm, I (partially) know the cause and solution. It is my cron script.
> Change it from:
> urllib.urlopen('http://localhost:54321/myapp/default/
> cron_job').read()
> into:
> urllib.urlopen('http://MY_DOMAIN:80/myapp/default/
> cron_job').read()
> then the cron script DOES visit the server in exactly same way as end
> user's browser, then serving by the same cache.ram instance. Problem
> disappear.
>
> I still don't know why a localhost:wsgi_port will cause problem. If
> anyone has a theory or explanation, I will be more than happy to know.
>
> That is it for today, my day X experience of web2py on webfaction.
>
> Regards,
> Iceberg
