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 > 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. > > Hancock, David (DHANCOCK) wrote: > >>With other factors held constant, File vs. Dynamic resulted in a 16% >>decrease in the benchmark's performance (one of the Webware example >>pages, 20,000 requests, 10 concurrently. That 16% may be what Matt had >>in mind as "way slower" but I thought it might help to put a number on >>it. >> >> >> >> > > ------------------------------------------------------- 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
