librelist archives

Re: [mongrel2] sticky sessions?

From:

Zed A. Shaw

Date:

2010-09-03 @ 06:59

On Fri, Sep 03, 2010 at 06:58:59AM +0200, Philippe Marschall wrote:
> I'm checking out whether Mongrel2 would work for our web framework
> [1]. We potentially have a lot of session state in the handlers that
> we can't easily replicate/serialize (continuations/stack
> frames/blocks/closures). Yeah, I know this is considered bad form but
> it's very convenient. With a traditional Apache deployment we would
> just use mod_proxy_balancer, add the handler id to the session id and
> Apache would pick the right handler. The way I understand Mongrel2 is
> that ZMQ will just select any handler. Is there a way to do sticky
> sessions, if so how?

So you need requests from one browser going back to the same handler
that started it all?  Like if Zed goes to your Seaside application and
he gets handler A for request 1, then request 2 through N have to go to
handler A?

I'd been thinking about this class of problem today, and for lack of a
better name let's call it "in-flight architecture upgrades". This would
be the same as, "We can only send X requests to our Rails handlers so
queue the overage at the server."  Or, "Send 40% of requests to that
server, but this server's better so send 50% there, and 10% to this
one."

My thinking has been two directions on this: filters and plain old
handlers.  With filters you'd have total control over the socket
operations so you could do whatever you wanted, but it'd harder to write
these and they'd have to run inside mongrel2, so crash causing if not
done right.  The alternative though is a special proxy handler that gets
all the requests and then does whatever kind of proxying/holding/routing
you need.  Disadvantage of that is it might be quite as fast, but it
would more robust and has multiprocessor advantages.

Can you give me more details on how your selection works currently?  Is
it off a cookie?  From a URL?  Maybe I cook up a demo to see how it
might work as a handler.

-- 
Zed A. Shaw
http://zedshaw.com/

 Hi,

On JBoss clustering one synced session stores across the
instances/boxes, and so the frontend could send to whatever backend
while keeping session state for the client.

/xraid

You can have lots of router handlers to extract the cookied session id
and get the results using other zeromq request to right handlers. This
way, your app handlers will be just zeromq req/reply apps and mongrel2
will be acting as distributed router/gateway.

2010/9/3 Peter Fagerlund <admin@iprobot.com>:
>  Hi,
>
> On JBoss clustering one synced session stores across the
> instances/boxes, and so the frontend could send to whatever backend
> while keeping session state for the client.
>
> /xraid
>

2010/9/3 Zed A. Shaw <zedshaw@zedshaw.com>:
> On Fri, Sep 03, 2010 at 06:58:59AM +0200, Philippe Marschall wrote:
>> I'm checking out whether Mongrel2 would work for our web framework
>> [1]. We potentially have a lot of session state in the handlers that
>> we can't easily replicate/serialize (continuations/stack
>> frames/blocks/closures). Yeah, I know this is considered bad form but
>> it's very convenient. With a traditional Apache deployment we would
>> just use mod_proxy_balancer, add the handler id to the session id and
>> Apache would pick the right handler. The way I understand Mongrel2 is
>> that ZMQ will just select any handler. Is there a way to do sticky
>> sessions, if so how?
>
> So you need requests from one browser going back to the same handler
> that started it all?  Like if Zed goes to your Seaside application and
> he gets handler A for request 1, then request 2 through N have to go to
> handler A?

Exactly.

> I'd been thinking about this class of problem today, and for lack of a
> better name let's call it "in-flight architecture upgrades". This would
> be the same as, "We can only send X requests to our Rails handlers so
> queue the overage at the server."  Or, "Send 40% of requests to that
> server, but this server's better so send 50% there, and 10% to this
> one."
>
> My thinking has been two directions on this: filters and plain old
> handlers.  With filters you'd have total control over the socket
> operations so you could do whatever you wanted, but it'd harder to write
> these and they'd have to run inside mongrel2, so crash causing if not
> done right.  The alternative though is a special proxy handler that gets
> all the requests and then does whatever kind of proxying/holding/routing
> you need.  Disadvantage of that is it might be quite as fast, but it
> would more robust and has multiprocessor advantages.
>
> Can you give me more details on how your selection works currently?  Is
> it off a cookie?  From a URL?  Maybe I cook up a demo to see how it
> might work as a handler.

It can be done either from a cookie for or an URL parameter. For
development an URL parameter is more convenient but for production
most people tend to want them as a cookie because it keeps the URL
cleaner and doesn't show up in the request logs.

We simply attach the handler id after a period to the session id. Then
we tell mod_proxy_balancer at which address it can find which handlers
and let it do it's magic. Basically reusing a lot of mod_jk/Tomcat
infrastructure and making it work for us. The whole setup is described
at [1].

So a parameter or would look like this:
_s=thesessionid.handlerid
with _s being the name of the session key.

 [1] 
http://book.seaside.st/book/advanced/deployment/deployment-apache/mod-proxy-balancer

Cheers
Philippe

On Fri, Sep 03, 2010 at 12:29:34PM +0200, Philippe Marschall wrote:
> 2010/9/3 Zed A. Shaw <zedshaw@zedshaw.com>:
> 
> So a parameter or would look like this:
> _s=thesessionid.handlerid
> with _s being the name of the session key.
> 
>  [1] 
http://book.seaside.st/book/advanced/deployment/deployment-apache/mod-proxy-balancer

Alright lemme try something out and see.  This could also be the time I
make cookies fully work since now the json convert can lose some of
them.

-- 
Zed A. Shaw
http://zedshaw.com/