Indeed it seemed as if the fact that there are concurrent visits meant that already another thread had issued the _cleanup, so there was some sort of race condition.
I did not like the fact that each thread (visit) performs a os.listdir and does a for loop over that list in order to see the creation time of the session file and then deletes it if it expired. Given that I may have more than 15000 sessions the os.listdir and for loop for each thread is a killer. What I did is rewrite is just comment out the cleanup in the session init and make a cron job that will delete my expired session files each 5 minutes. 2010/6/14 Emiliano Martinez Contreras <[email protected]> > Hi guys, > > I keep finding in my apache error log errors like this one: > > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.63] > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] Traceback (most > recent call last): > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] File > "/usr/lib64/python2.5/site-packages/web/application.py", line 209, in > process > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] return > p(lambda: process(processors)) > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] File > "/usr/lib64/python2.5/site-packages/web/session.py", line 55, in _processor > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] > self._cleanup() > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] File > "/usr/lib64/python2.5/site-packages/web/session.py", line 135, in _cleanup > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] > self.store.cleanup(timeout) > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] File > "/usr/lib64/python2.5/site-packages/web/session.py", line 234, in cleanup > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] atime = > os.stat(path).st_atime > [Mon Jun 14 12:59:23 2010] [error] [client 192.168.200.66] OSError: [Errno > 2] No such file or directory: > '/tmp/sessions/42ce5fb983010730b7417abd40498aea07bde > 615' > > Tons of them. It is as if another thread had executed the session cleanup > routine already and so the particular thread that raises the exception is > unable to find the session diskstore file to delete. > > I am using sessions as in the subapp session support example, with a > load_hook preprocessor: > > def session_hook(): > web.ctx.session = session > > [...] > > app = web.application(urls, locals()) > web.config.debug = False > web.config.session_parameters['cookie_name'] = 'whatever' > web.config.session_parameters['timeout'] = 30 * 60 > session = web.session.Session(app, web.session.DiskStore('/tmp/sessions'), > initializer={'user': 0, 'nick': ''}) > > [...] > > app.add_processor(web.loadhook(session_hook)) > > [...] > > application = app.wsgifunc() > > Did anyone already come across this issue? I assume it is probably not > important since the sessions expires and is deleted correctly, but I do not > like my error log being flooded with those messages (I am trying out in a > site with a high load). > > Thanks! > -- *********************************************** Emiliano Martinez Contreras - Telecommunications Engineer (Security and Networks) Urb. Guadalpark Fase 1, casa 12 29600 Marbella (Malaga) Spain Mobile: +34 625 86 16 83 [SPAIN] +33 (0)6 07 37 55 79 [FRANCE] *********************************************** -- You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/webpy?hl=en.
