> -----Original Message----- > From: Matt Pitts [mailto:[email protected]] > Sent: Monday, January 26, 2009 10:53 AM > To: The elegant MVC web framework > Subject: RE: [Catalyst] Production session issue - commercial support > inquiry? > > > -----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?
Ok, now that I've looked at this some more I think this may actually be caused by the proxy server. Currently the app is load balanced behind an Apache/mod_proxy_balancer instance and I'm unable to replicate the problem when not going through the proxy. I had spent quite a bit of time looking at the proxy back when these issues started, but now I'm doing it again because it's about the only thing left. If it is Apache, I imagine it's related to mod_cache, although I *thought* I had it properly configured. As an exercise; after a simple restart of Apache on the proxy I was *unable* to duplicate the cookie issue after ten minutes of trying whereas this morning I had been able to do it after just a few refreshes. Has anyone experienced good/bad things with Apache as a frontend proxy/balancer/cache? I've seen mention of Varnish on this list as a good frontend proxy. Any personal recommendations of it or others? TIA -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/
