[Catalyst] Production session issue - commercial support inquiry?

Matt Pitts mpitts at a3its.com
Mon Jan 26 15:53:03 GMT 2009

> -----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
> 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
> (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
> to provide direct HTTP access to areas where SSL isn't needed. I
> 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.
> -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

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.

-matt pitts

More information about the Catalyst mailing list