[Catalyst] Production session issue - commercial support inquiry?

[J. Shirley]

On Mon, Jan 26, 2009 at 12:27 PM, Matt Pitts <mpitts at a3its.com> wrote:
>> -----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
>

Varnish is very good, but it simply doesn't cache something if it has
a session cookie for exactly this reason.  There are ways to configure
it to do so, but if your performance requirements are such that you
must proxy you may want to couple Varnish with ESI.

Jay Kuri wrote a nice article on this:
http://www.catalystframework.org/calendar/2008/17

-J