Forcing client to wait for a specific backend to finish connecting

27 views
Skip to first unread message

sawyer x

unread,
Jul 10, 2012, 6:17:16 AM7/10/12
to per...@googlegroups.com
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

unread,
Jul 10, 2012, 6:26:46 AM7/10/12
to per...@googlegroups.com

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

unread,
Jul 10, 2012, 3:23:01 PM7/10/12
to per...@googlegroups.com
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

unread,
Jul 10, 2012, 6:52:30 PM7/10/12
to per...@googlegroups.com
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

unread,
Jul 10, 2012, 7:05:00 PM7/10/12
to per...@googlegroups.com
> 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

unread,
Jul 10, 2012, 7:14:39 PM7/10/12
to per...@googlegroups.com
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

unread,
Jul 11, 2012, 4:29:30 AM7/11/12
to per...@googlegroups.com
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

unread,
Jul 12, 2012, 11:37:19 PM7/12/12
to per...@googlegroups.com
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

unread,
Jul 13, 2012, 8:29:49 AM7/13/12
to per...@googlegroups.com

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

unread,
Jul 17, 2012, 10:20:30 AM7/17/12
to per...@googlegroups.com
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

unread,
Jul 17, 2012, 10:34:49 AM7/17/12
to per...@googlegroups.com

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

unread,
Jul 17, 2012, 12:24:42 PM7/17/12
to per...@googlegroups.com
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

unread,
Jul 24, 2012, 4:08:12 PM7/24/12
to per...@googlegroups.com
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

unread,
Jul 25, 2012, 11:05:34 AM7/25/12
to per...@googlegroups.com
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

unread,
Jul 25, 2012, 11:10:41 AM7/25/12
to per...@googlegroups.com

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.

Reply all
Reply to author
Forward
0 new messages