Load balancing with one session per image

[Bob Nemec]

How can we load balance across a number of VW Seaside images where we limit each image to one Seaside session?  So, once a Seaside session is affiliated with a VW image, no other Seaside session can be serviced by that image.  The image is only available when the session expires or the user logs out.

For now we're using Apache and we're investigating Cherokee and Nginx.

Here's some background: we've added a Seaside interface to a current VW application.  The Seaside interface is designed as just another UI layer to the domain.  There is enough meta data in the framework to drive a fairly thin Seaside layer which duplicates virtually all of the full (fat) client behaviour.  But, because of framework restrictions, we'll only support one Seaside session per image.  Since we're only looking at supporting around 50 concurrent sessions, we don't feel the need to re-engineer the application framework code to support multiple session.

The Seaside components are built widget by widget from the VW windows spec, with callback behaviours triggering matching VW widget behaviours.  We trap prompts and window open events by using Process>>#environmentAt: to pass our Seaside session between the components and the domain.

So far, all of this is working fine.  It is actually quite cool to show the full client side by side with a domain browser.

Thanks for any help,

Bob Nemec
Cherniak Software

[Boris Popov-2]

The following is quite thin technical-detail wise, but might give you
some ideas nonetheless,

http://tinyurl.com/n8uktc

-Boris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Bob
Nemec
Sent: Monday, June 22, 2009 8:49 AM
To: [hidden email]
Subject: [Seaside] Load balancing with one session per image


How can we load balance across a number of VW Seaside images where we
limit
each image to one Seaside session?  So, once a Seaside session is
affiliated
with a VW image, no other Seaside session can be serviced by that image.

The image is only available when the session expires or the user logs
out.

For now we're using Apache and we're investigating Cherokee and Nginx.

Here's some background: we've added a Seaside interface to a current VW
application.  The Seaside interface is designed as just another UI layer
to
the domain.  There is enough meta data in the framework to drive a
fairly
thin Seaside layer which duplicates virtually all of the full (fat)
client
behaviour.  But, because of framework restrictions, we'll only support
one
Seaside session per image.  Since we're only looking at supporting
around 50
concurrent sessions, we don't feel the need to re-engineer the
application
framework code to support multiple session.

The Seaside components are built widget by widget from the VW windows
spec,
with callback behaviours triggering matching VW widget behaviours.  We
trap
prompts and window open events by using Process>>#environmentAt: to pass
our
Seaside session between the components and the domain.

So far, all of this is working fine.  It is actually quite cool to show
the
full client side by side with a domain browser.

Thanks for any help,

Bob Nemec
Cherniak Software
--
View this message in context:
http://www.nabble.com/Load-balancing-with-one-session-per-image-tp241498
15p24149815.html
Sent from the Squeak - Seaside mailing list archive at Nabble.com.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Bob Nemec]

Boris,
Thanks, that's one of the threads I read.  I can see how it would be useful as a way to manage the pool of images, but not in how it could isolate one session per image.  Requests get proxied to the image's dedicated internal port if it the port is open.  What I'd like is some way of indicating that the port is not available, even though it's open.

FWIW: we're thinking of keeping a fixed number of images up and have a hard limit to the number of concurrent sessions.  Given the stats from how the full client is used, we don't think that will be a problem.

Bob

Boris Popov-2 wrote:

The following is quite thin technical-detail wise, but might give you
some ideas nonetheless,

http://tinyurl.com/n8uktc

-Boris

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bob
Nemec
Sent: Monday, June 22, 2009 8:49 AM
To: [e-mail]
Subject: [Seaside] Load balancing with one session per image


How can we load balance across a number of VW Seaside images where we
limit
each image to one Seaside session?  So, once a Seaside session is
affiliated
with a VW image, no other Seaside session can be serviced by that image.

The image is only available when the session expires or the user logs
out.

For now we're using Apache and we're investigating Cherokee and Nginx.

Here's some background: we've added a Seaside interface to a current VW
application.  The Seaside interface is designed as just another UI layer
to
the domain.  There is enough meta data in the framework to drive a
fairly
thin Seaside layer which duplicates virtually all of the full (fat)
client
behaviour.  But, because of framework restrictions, we'll only support
one
Seaside session per image.  Since we're only looking at supporting
around 50
concurrent sessions, we don't feel the need to re-engineer the
application
framework code to support multiple session.

The Seaside components are built widget by widget from the VW windows
spec,
with callback behaviours triggering matching VW widget behaviours.  We
trap
prompts and window open events by using Process>>#environmentAt: to pass
our
Seaside session between the components and the domain.

So far, all of this is working fine.  It is actually quite cool to show
the
full client side by side with a domain browser.

Thanks for any help,

Bob Nemec
Cherniak Software
--
View this message in context:
http://www.nabble.com/Load-balancing-with-one-session-per-image-tp241498
15p24149815.html
Sent from the Squeak - Seaside mailing list archive at Nabble.com.

_______________________________________________
seaside mailing list
[e-mail]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[e-mail]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Yanni Chiu]

Bob Nemec wrote:
> How can we load balance across a number of VW Seaside images where we limit
> each image to one Seaside session?  So, once a Seaside session is affiliated
> with a VW image, no other Seaside session can be serviced by that image.
> The image is only available when the session expires or the user logs out.

Here is an untested idea. If a request comes in without a session key,
then redirect the request to an assigner image that can assign a session
key and an affiliated worker image. Then another redirect would get the
load balancer to send the request to the right worker image.

If you're using GemStone (or even a relational DB), then a list of
available worker images could be kept. Each image would
register/unregister it's availability, by adding/removing itself to/from
the collection. Initially, the image's status would be session-is-free.

The assigner application would chose an available worker image, which
has image status: session-is-free. The assigner would change the status
to: session-is-assigned. Then the redirect is done to the assigned
worker image.

When the session terminates, the worker image would update it's status
to: session-is-free - thus returning itself to the worker image pool.

Maybe you could have the assigner functionality run in every worker
image, instead of only in a single designated image. In this case, the
assigner code would need to test for session-is-free and set
session-is-assigned in a single transaction.

Hope this helps.

--
Yanni Chiu

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Bob Nemec]

Yanni Chiu wrote:

... Here is an untested idea. If a request comes in without a session key, then redirect the request to an assigner image that can assign a session key and an affiliated worker image. Then another redirect would get the load balancer to send the request to the right worker image. ... Yanni Chiu

That's the direction we're thinking of: a dispatcher image that knows the available applications images and also prompts for login information. I had hoped, however, that this problem had already been solved and well tested by someone else ;-) Oh well... I'll let you know how it goes. Bob Nemec

[Reg Krock]

The approach below is along the lines taken by a major US company who uses
VA. The other factor they ran into was what to do when the session had
'timed' out. They wanted a user to be able to continue with a session even
though it had 'time out. They needed a fail over mechanism to assign the
'timed out' session to a new server and move the transaction information
to the new server. You may not have that problem.

The solution was home grown.

> Bob Nemec wrote:
>> How can we load balance across a number of VW Seaside images where we
>> limit
>> each image to one Seaside session?  So, once a Seaside session is
>> affiliated
>> with a VW image, no other Seaside session can be serviced by that image.
>> The image is only available when the session expires or the user logs
>> out.
>
> Here is an untested idea. If a request comes in without a session key,
> then redirect the request to an assigner image that can assign a session
> key and an affiliated worker image. Then another redirect would get the
> load balancer to send the request to the right worker image.
>
> If you're using GemStone (or even a relational DB), then a list of
> available worker images could be kept. Each image would
> register/unregister it's availability, by adding/removing itself to/from
> the collection. Initially, the image's status would be session-is-free.
>
> The assigner application would chose an available worker image, which
> has image status: session-is-free. The assigner would change the status
> to: session-is-assigned. Then the redirect is done to the assigned
> worker image.
>
> When the session terminates, the worker image would update it's status
> to: session-is-free - thus returning itself to the worker image pool.
>
> Maybe you could have the assigner functionality run in every worker
> image, instead of only in a single designated image. In this case, the
> assigner code would need to test for session-is-free and set
> session-is-assigned in a single transaction.
>
> Hope this helps.
>
> --
> Yanni Chiu
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside