Forcing client to wait for a specific backend to finish connecting

[sawyer x]

That's a mouthful of a topic.

I'm trying to assign clients with a specific backend. However, if all connect aheads are exhausted, and the backend is in the "pending_connects" attribute waiting for the connection to finish, Perlbal will meanwhile assign the client with a different backend. Calling "spawn_backends" method won't really fix it, since it will still go through the "pending_connects" cycle while Perlbal will give the user a (most likely different) server.

Is there a way to hold the user till a specific server is connected and let it use that one?

[sawyer x]

Is there a suggested way to pick a backend to which a client will connect?
(even if it's still in "pending_connects" or not present either in "pending_connects" nor in "bored_backends")

[dormando]

Perlbal's meant to keep a disconnection between client and backend.
Strongarming it may not work terribly well...

It's not clear if you're trying to connect it to a specific server, or
literally a specific connection to a specific server? If the former, you
can set up one pool per server and use a selector to assign the client.

[sawyer x]

On Tue, Jul 10, 2012 at 10:23 PM, dormando <dorm...@rydia.net> wrote:

> On Tue, Jul 10, 2012 at 1:17 PM, sawyer x <xsaw...@gmail.com> wrote:
>
> Is there a suggested way to pick a backend to which a client will connect?
> (even if it's still in "pending_connects" or not present either in "pending_connects" nor in "bored_backends")

Perlbal's meant to keep a disconnection between client and backend.
Strongarming it may not work terribly well...

Yet, in the matter of a sticky session or reproxying, there's a purpose to connecting the two.

It's not clear if you're trying to connect it to a specific server, or
literally a specific connection to a specific server? If the former, you
can set up one pool per server and use a selector to assign the client.

I want to be able to implement a sticky session. Send a user a header which relates to a specific server (so far so good) and when the user comes in, to get them to get *that* specific server (as long as it's in the pool of the server the user is going to).

I was able to accomplish it but it a pretty gross way of either playing with bored_backends or creating a new connection assign the client to. Any help to make it cleaner would be greatly appreciated! :)

[dormando]

> On Tue, Jul 10, 2012 at 10:23 PM, dormando <dorm...@rydia.net> wrote:
> > On Tue, Jul 10, 2012 at 1:17 PM, sawyer x <xsaw...@gmail.com> wrote:
> >
> > Is there a suggested way to pick a backend to which a client will connect?
> > (even if it's still in "pending_connects" or not present either in "pending_connects" nor in "bored_backends")
>
> Perlbal's meant to keep a disconnection between client and backend.
> Strongarming it may not work terribly well...
>
>
> Yet, in the matter of a sticky session or reproxying, there's a purpose to connecting the two.

I get that; except perlbal was designed specifically for the case of
sticky sessions being a bad idea.

> It's not clear if you're trying to connect it to a specific server, or
> literally a specific connection to a specific server? If the former, you
> can set up one pool per server and use a selector to assign the client.
>
>
> I want to be able to implement a sticky session. Send a user a header which relates to a specific server (so far so good) and when the user comes
> in, to get them to get *that* specific server (as long as it's in the pool of the server the user is going to).
>
> I was able to accomplish it but it a pretty gross way of either playing with bored_backends or creating a new connection assign the client to. Any
> help to make it cleaner would be greatly appreciated! :)

If you do the pool trick I mentioned above, it should work fine. You can
look at the selector examples and pick one that can examine session
cookies and direct them back to a particular service, which has a
particular pool. then you end up with one service/pool per server...

[sawyer x]

On Wed, Jul 11, 2012 at 2:05 AM, dormando <dorm...@rydia.net> wrote:

> On Tue, Jul 10, 2012 at 10:23 PM, dormando <dorm...@rydia.net> wrote:
>       > On Tue, Jul 10, 2012 at 1:17 PM, sawyer x <xsaw...@gmail.com> wrote:
>       >
>       > Is there a suggested way to pick a backend to which a client will connect?
>       > (even if it's still in "pending_connects" or not present either in "pending_connects" nor in "bored_backends")
>
> Perlbal's meant to keep a disconnection between client and backend.
> Strongarming it may not work terribly well...
>
>
> Yet, in the matter of a sticky session or reproxying, there's a purpose to connecting the two.

I get that; except perlbal was designed specifically for the case of
sticky sessions being a bad idea.

I'm not sure I understand that sentence. Are sticky sessions a bad idea because of the way Perlbal was designed or was Perlbal designed with the thought that sticky sessions are a bad idea?

If the latter, is the something more recommended instead?

 

>       It's not clear if you're trying to connect it to a specific server, or
>       literally a specific connection to a specific server? If the former, you
>       can set up one pool per server and use a selector to assign the client.
>
>
> I want to be able to implement a sticky session. Send a user a header which relates to a specific server (so far so good) and when the user comes
> in, to get them to get *that* specific server (as long as it's in the pool of the server the user is going to).
>
> I was able to accomplish it but it a pretty gross way of either playing with bored_backends or creating a new connection assign the client to. Any
> help to make it cleaner would be greatly appreciated! :)

If you do the pool trick I mentioned above, it should work fine. You can
look at the selector examples and pick one that can examine session
cookies and direct them back to a particular service, which has a
particular pool. then you end up with one service/pool per server...

I could try and create pools on start-up for each server (pool name would be the server's hashed ID) and then have the request forward it to the proper pool. Unfortunately the documentation is scarce. Any quick tips or references for either creating pools (via code) and/or assign clients to them from hooks?

Thank you for the attention and help. :)

[sawyer x]

On Wed, Jul 11, 2012 at 2:14 AM, sawyer x <xsaw...@gmail.com> wrote:

If you do the pool trick I mentioned above, it should work fine. You can
look at the selector examples and pick one that can examine session
cookies and direct them back to a particular service, which has a
particular pool. then you end up with one service/pool per server...

I could try and create pools on start-up for each server (pool name would be the server's hashed ID) and then have the request forward it to the proper pool. Unfortunately the documentation is scarce. Any quick tips or references for either creating pools (via code) and/or assign clients to them from hooks?

Hoping I'm not bombing the list, but I'm quite anxious to get this worked out.

So how would I assign a pool to a user from a selector service?

[dormando]

Set up selector (See VPath/etc for examples)

Add one service per "server"

Add one pool per "server"

Add each unique pool to each unique service

Ding? Bit wasteful but oh well.

[sawyer x]

I ended up doing about the same thing:
I lazily create another pool for each backend, and another service on the fly.
Then I direct the user to that new service.
 

Ding? Bit wasteful but oh well.

Actually the end result was rather good. I simply create the new service according to as many preferences I can from the original service. I also do not enable it. By keeping it disabled, I can use it, but it doesn't open a new listening socket, and it reuses the original service's socket. This means I'm making use of all the connect-aheads, SSL works, and everything else just fine. Pretty cool. :)

It's up on CPAN as Perlbal::Plugin::SessionAffinity.

Thanks for the advice!
s.

[Bill Moseley]

On Tue, Jul 10, 2012 at 3:52 PM, sawyer x <xsaw...@gmail.com> wrote:

I want to be able to implement a sticky session. Send a user a header which relates to a specific server (so far so good) and when the user comes in, to get them to get *that* specific server (as long as it's in the pool of the server the user is going to).

Quick question:

Why do you need sticky sessions?  Why is it necessary that a user uses the same machine for every request?

--
Bill Moseley
mos...@hank.org

[sawyer x]

Multiple backends that do not share the same session data.

Not everyone has a LAN setup, and an NFS or Riak or CouchDB or whatever for their session data. If you go to a different backend, you lose the session.

[Matthew Summers]

This really sounds like a software design problem. Perhaps you could
consider using memcache with SASL to store session data for all
backends.

--
M. Summers

"...there are no rules here -- we're trying to accomplish something."
- Thomas A. Edison

[sawyer x]

On Tue, Jul 17, 2012 at 7:24 PM, Matthew Summers <msumm...@gmail.com> wrote:

On Tue, Jul 17, 2012 at 9:34 AM, sawyer x <xsaw...@gmail.com> wrote:
> On Tue, Jul 17, 2012 at 5:20 PM, Bill Moseley <mos...@hank.org> wrote:
>> Quick question:
>>
>> Why do you need sticky sessions?  Why is it necessary that a user uses the
>> same machine for every request?
>
>
> Multiple backends that do not share the same session data.
>
> Not everyone has a LAN setup, and an NFS or Riak or CouchDB or whatever for
> their session data. If you go to a different backend, you lose the session.

This really sounds like a software design problem.

This is by no means a software design problem. It's a consideration that many face when they have backends that cannot share session data. If you're using two (or more) different server providers (we're not all in the cloud, of course), you might not be able to effectively share any data between them because the latency between them can be too high. This is something that actually happens to a lot of shops.
 

Perhaps you could
consider using memcache with SASL to store session data for all
backends.

The problem is latency, not the storage method. I can use Memcache, Riak, CouchDB or others, but it doesn't change the latency problem between them. Actually, it adds an additional problem (which is especially evident in CouchDB) of making sure you collate the session data from different workers correctly. We've actually tried all those I've mentioned (and more) and had these problems.

Session affinity is a different way of handling this situation, and although it has its disadvantages, it works quite well.

[Bill Moseley]

On Tue, Jul 24, 2012 at 1:08 PM, sawyer x <xsaw...@gmail.com> wrote:

The problem is latency, not the storage method. I can use Memcache, Riak, CouchDB or others, but it doesn't change the latency problem between them. Actually, it adds an additional problem (which is especially evident in CouchDB) of making sure you collate the session data from different workers correctly. We've actually tried all those I've mentioned (and more) and had these problems.

 

Does your app use a database that's shared by the server pool? 

--
Bill Moseley
mos...@hank.org

[sawyer x]

Yes, and no.

'Yes' in that there is data accessible on all servers, because they are all slaves of a master database.
'No' in that they cannot write anything to the database that others will see, since it's their own copy.

Thus, it cannot be used for session storage.