From: Ben Parker <ben@we...> - 2003-08-26 20:06:16
Please let me know if I should be posting this to Webware-discuss instead.
It seemed a little low level for that list.
I'm running a couple major sites with Webware 0.8 and just starting running
into some issues with session storage. The site is using the
SessionDynamicStore and I've gotten KeyError's in places where they
we have a servlet that searches through all the sessions, and I've seen this
for s in self.transaction().application().sessions().values():
File "./WebKit/SessionStore.py", line 116, in values
File "./WebKit/SessionStore.py", line 116, in <lambda>
File "./WebKit/SessionDynamicStore.py", line 74, in __getitem__
File "./WebKit/SessionMemoryStore.py", line 33, in __getitem__
So just in getting the values() of the session store there are KeyErrors.
The partial traceback above seems to be a threading issue due to inadequate
use of locking. SessionStore does not define the keys() function since
subclasses obviously store sessions in different ways, but it does define
values() which uses map() to iterate over the keys and pull the sessions
from the store. The problem seems to be that sessions can be deleted from
the MemoryStore between the time the keys are generated and the time
values() tries to pull the actual sessions from the store.
My second issue is related to SessionFileStore. SessionFileStore's
__getitem__ function will raise a KeyError if the data in a session is
corrupt, but then the session remains on the drive in it's corrupted state.
This means that a single corrupted session will break all calls to values()
from SessionFileStore (or SessionDynamicStore). I submitted a bug report
about this one. The SessionFileStore should at a minimum raise a different
type of error so that the caller can react to corrupted data vs a missing
session. I would like to also see the corrupted session either deleted (the
exception could contain the corrupted data for review by support staff) or
moved into another directory to prevent further errors.
This is really biting us. Because right now the only thing I can do is catch
the KeyErrors from SessionDynamicStore that are really being through by
SessionMemoryStore or SessionFileStore. There's no way to tell which store
threw the error programmatically without digging into the traceback at
runtime which I don't want to do. I'd rather fix the session stores.
Has anyone else built a demanding enough site to expose these errors?
Thanks in advance for any feedback - Ben