[Catalyst] Production session issue - commercial support inquiry?

[Matt Pitts]

> -----Original Message-----
> From: Matt Pitts [mailto:mpitts at a3its.com]
> 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:mpitts at a3its.com]
> > 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