On Feb 21, 2008, at 11:18 AM, Matt Pitts wrote:
One was running:
Catalyst::Authentication::Store::DBIx::Class 0.104
And the other:
Catalyst::Plugin::Authentication::Store::DBIx::Class 0.10
This is the whole reason I'm moving to PAR-based deployments.
Another good way to keep this sort of
> -Original Message-
> From: Jay K [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 21, 2008 1:35 PM
> To: The elegant MVC web framework
> Subject: Re: [Catalyst] Distributed session storage problems/questions
>
> Hello Matt,
>
> This looks like a version
Hello Matt,
This looks like a version mismatch of the
Catalyst::Authentication::Store::DBIx::Class module on the two machines.
Recently I added functionality to the module which allow users to
avoid the DB hit when restoring a user from the session, part of this
change entailed changing t
4. Is it just crazy to run a load balanced setup without some type of
sticky session setup on the proxy? If so, any implementations of this
using Apache 2.x mod_proxy(_balancer) as the frontend would be greatly
appreciated.
<
You should only use "sticky sessions" as a performance enhancer (
> -Original Message-
> From: Lars Balker Rasmussen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 20, 2008 1:35 PM
> To: The elegant MVC web framework
> Subject: Re: [Catalyst] Distributed session storage problems/questions
>
> On Wed, Feb 20, 2008 at 01:08:0
On Wed, Feb 20, 2008 at 01:08:08PM -0500, Matt Pitts wrote:
> 1. What is the acceptable way to use memcached for session storage? Is
> it using C::P::Session::Store::Memcached or is it
> C::P::Session::Store::Cache in conjunction with C::P::Cache::Memcached?
Well, either, really, they do much the
We have a load balanced application where the proxy does *not* force any
type of sticky session with each backend. The app was running in
production as a single instance (pre load-balanced) and we moved it
behind the proxy to be able to add backends and make it load balanced. I
had the app in test
