> -----Original Message----- > From: Matt Pitts [mailto:[email protected]] > Sent: Friday, January 23, 2009 4:22 PM > To: The elegant MVC web framework > Subject: RE: [Catalyst] Production session issue - commercial support > inquiry? > > We had another major incident of session cross-over this morning which > happened right after I pushed out a small change and reload/restarted > the instances. > > I personally experienced the session cross-over twice. In each instance > I captured my session id and went to compare it to a dump of all > sessions and found that no other session had the same data as mine. > However, the 2 session id's *were* the same and I had cleared my > cookies > between these two instances. > > So, I could be getting dups out of generate_session_id, but I'm also > wondering if it's not some weird process issue where the same session > ID > is not being generated twice, but is just getting shoved into the > response headers of 2 different requests. Anyone know if this is > plausible? > > If P::Session is generating duplicate IDs I doubt I'd be the only one > having the issue. BTW, the cat app only averages about 12 req/s and > this > issue doesn't seem to be very dependent on traffic. > > Along the lines of the process question... > > What, if any, are the ramifications of running two instances of the app > (one HTTP::Prefork and one FCGI) out of the same "root". In my > particular case the FCGI instance is for talking to a local Apache > instance that is providing SSL access and the HTTP::Prefork instance is > to provide direct HTTP access to areas where SSL isn't needed. I wasn't > originally worried about this because they're separate process, but > right now I'm looking at anything that might be causing my problems. > Could a situation like this cause strange behavior in regards to > session > ids. > > Right now I have a set of changes primed to push out that completely > removed P::Session and uses P::CookiedSession instead. I guess if I > don't get a resolution to the issues with P::Session by Monday I'll be > pushing this out and then I'll know it's not P::Session problem if it > continues. > > TIA > > -matt
My saga continues... I have pushed out my CookiedSession based changes and can confirm that the cross-over issues are still present. Myself and my client have been able to replicate the issue twice by clearing cookies and accessing Cart related pages. After a few refreshes my Cart page in IE shows the same Cart that I built out in FF and after examining the cookie headers the encrypted data appears to be identical. P::Session and its related modules have been completely removed from use Catalyst qw/.../, so I now know that it's not being caused by these modules. Now that everything is stored in the browser's cookie, how is it possible that two browsers get sent the same cookie header? I've gone back over all my custom plugins and can say that all the following are true: - all MyPlug->setup methods call $c->NEXT::setup(@_) *and* return $c - all other overridden methods call $c->NEXT::<methodname>(@_) - the only overridden methods across all plugins are setup, prepare_action, and dispatch I'm going back to Sergio's suggestion that a package var or coderef may be the culprit, but I just can't fathom any places in the code that I'm even using either of these facilities incorrectly, much less where doing so would cause responses to get crossed like this. Any suggestions are extremely welcome. v/r -matt pitts _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
