Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Tracy S. Ruggles wrote:
> Below is a very simple servlet and class that demonstrates what
> happens. I tried switching the SessionStore to 'Memory', but it
> doesn't seem to like trying to reload the file from the Sessions/
> <id>.ses file:
>> Error loading session from disk: 20050617152441-
>> [Fri Jun 17 15:25:04 2005] [error] WebKit: Error while executing
>> script None Traceback (most recent call last):
>> File "WebKit/SessionFileStore.py", line 53, in __getitem__
I tried your example using the Memory store but I couldn't get it to work at
all until I moved the History class into a separate module _outside_ of the
context directory. Then the Memory store worked OK for me, and did in fact
unpickle the session correctly (and only once). Pickling seems to be a bit
picky about the path of the module that contains the object you are trying
> To see how the servlet below re-loads the pickled data twice, just
> put this into a context directory and go to http://localhost/
> <adapter>/SessionTest -- reload a few times, then kill your appserver
> (to see it write out the pickled session file), and then start the
> appserver and visit that page again -- you'll see the print statement
> called twice.
Yes, I was able to reproduce that.
> Also, below the test servlet, I included a diff of
> SessionFileStore.py where I commented out the lines that does the
> secondary __getitem__ of the session identifier. I'm not sure what
> implications that might have though...
I'm not really sure. I suspect the problem is a logic error in
SessionDynamicStore that has to do with the fact that it is trying to re-use
the functionality from SessionFileStore in an inappropriate way. I'm not
sure there's a simple fix.
My recommendation is still to try to get the Memory store working.
Geoffrey Talvola wrote:
> I'm not really sure. I suspect the problem is a logic error in
> SessionDynamicStore that has to do with the fact that it is trying to
> re-use the functionality from SessionFileStore in an inappropriate
> way. I'm not sure there's a simple fix.
> My recommendation is still to try to get the Memory store working.
Actually, I think I did figure out the problem with the Dynamic store. I
just checked in a fix to Subversion along with some other improvements I've
been meaning to check in for a while.
Give it a try and let me know if it works.