> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, October 20, 2004 3:57 PM > To: [EMAIL PROTECTED] > Subject: RE: [Webware-discuss] session strangeness > > > Hey, thanks everyone for coming to my rescue on this. Good information. > I think I've isolated whats going on a bit further. In order to protect > our 'posts' from user triggered refreshes, we store the results in > session, use a sendRedirect to dispatch to a get, load the results out of > store and paint the page (Cheetah templates noise in there too). I found > that after doing this 'dispatching' I brought the server up and down we > see this error. > > I was engineering this first pass as dispatching and was lazily leaving > the results in session until I got another post at which time I'd clean > out the session and reload it with the new results. Any time I bounced > the server I saw this error until I added code that on successful results > being dispatched and painted, I actually pull the results out of session > permanently. > > Now I only get this error if you start a post, and an error is dispatched. > Because I need to reload the form into the page that the post was > submitted to, I can't clean it out of session (protecting against the user > refresh). So if I stop and bounce the server at this point I get the > error and have to clean out the cookies manually. > > My suspicion is that because I'm shoving actual python instance objects > into the session (one that abstracts the form data, and another that > contains read only data needed to present the form) the DYNAMIC mode is > deciding somehow to shove those things into file storage rather than keep > them in memory. Then when I restart the server, the user's cookie still > refers to the SID that points to that file, which no longer exists because > of the server bounce. I haven't tried to debug any of this, so its > possible that I'm completely full of it, but its the theory I'm using > right now. > > I think that leaves my options as: find a light-weight translation for the > results I need to store in the session and hope webware doesn't feel > compelled to store it to file. Or I can switch to using only memory based > session management and hope that it doesn't cause server slowdown if I > have heavy objects in session. And finally I can simply only store a > session id of my own in the session, and rely on my app database to manage > my session objects myself. > > I'm going to look into option 2 first and at the same time see what > version of the source I've got compared to whats in cvs right now. > > thanks a ton everyone for the great ideas. I appreciate it hugely... > > jeremy
Hey jeremy - I want to correct your theory. The dynamic session store doesn't do any introspection before deciding how to store session objects. That is, the types of values you add to the session do not affect how the dynamic session store treats that session object. As Matt pointed out, your problem is probably that the sessions cannot be pickled, but actually its unpickled in this case. When Webware shuts down, the dynamic session store will try to encode the sessions (using cPickle or pickle) and store them as files on the disk. If the session cannot be encoded, it's dropped. Try and reproduce/confirm this error using only one session: - Stop Webware - Delete all the session files in .../Webapps/Sessions/ (or wherever you are storing them) - Close all your browsers, delete local cookies, blah blah - Restart Webware - Create your scenario, then stop Webware Now here's the fun part: - If you do not have a new session file in the Sessions/ directory, you have a pickling problem. Your session could not be encoded and was dropped. - However, your problem is that there IS a session file in the Sessions/ directory, but when the appserver starts up again, the SessionFileStore cannot decode it and raises a KeyError. That's your posted error on line 55 of SessionFileStore, upon which SessionDynamicStore relies. So I think you have an unpickling problem. Are you storing anything with a socket connection, db connection or anything else that would be pickled but not unpickled? To help debug, hack into SessionFileStore.py and change line 55 to simply "raise" the exception thrown by the decoder, instead of raising a new KeyError. Hope that helps - Ben > > > Thanks, Matt--that's useful. We never (purposely) put anything but > > strings > > into the session store, so that skews our results in the "good" > > direction. > > > > Cheers! > > -- > > David Hancock > > > > -----Original Message----- > > From: Matt Feifarek [mailto:[EMAIL PROTECTED] > > Sent: Wed 10/20/2004 6:12 PM > > To: Hancock, David (DHANCOCK) > > Cc: [EMAIL PROTECTED] > > Subject: Re: [Webware-discuss] session strangeness > > > > Thanks for that. > > > > I guess that it's not "way" :-) > > > > But it does depend on what gets pickled; if it stays in memory, there's > > no pickling. I've noticed for example that pickling new style classes > > (with the getstate/setstate stuff) is pretty slow. Typical session stuff > > like strings and ints should be no problem. > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
