search

SeasideSt / Seaside

The framework for developing sophisticated web applications in Smalltalk.
MIT License
518 stars 71 forks source link

ImageSegments for smoother upgrades that don't kill sessions? #99

Closed GoogleCodeExporter closed 1 year ago

GoogleCodeExporter commented 9 years ago 
Is there a possibility of using ImageSegments to partition out the state of a 
Seaside node so 
upgrades can be rolled out to load balanced farms by having the running node 
save and quit and 
immediately start up a new version to replace it so users only notice a 
momentary pause but not 
have their sessions blown away?  It's one thing to hot upgrade a site running 
in a single image with 
VNC or the web interface, but if you're load balancing a whole slew of nodes 
that's just not going to 
work. It's much easier to copy out a new image and restart all the nodes.

I don't actually know if this will work, but if ImageSegments can save blocks 
and continuations then 
isn't this possible?

Original issue reported on code.google.com by ramon.l...@gmail.com on 13 Jul 2008 at 4:17

GoogleCodeExporter commented 9 years ago 
Do you mean only to persist sessions? Or other state as well like for example 
applications and their configuration?

Original comment by philippe...@gmail.com on 13 Jul 2008 at 4:32

GoogleCodeExporter commented 9 years ago 
Yes, to persist session just long enough to kill and bring up a new image with 
a new version of the application 
without blowing away all the current users.  In .Net I keep my session data in 
memcached to allow this, but in 
Squeak, things aren't so simple.

Original comment by ramon.l...@gmail.com on 13 Jul 2008 at 4:44

GoogleCodeExporter commented 9 years ago 
I don't think that this easily works. The continuations and callback blocks 
reference state that potentionally 
pulls in the whole image (through the contexts).

Original comment by renggli on 13 Jul 2008 at 5:20

GoogleCodeExporter commented 9 years ago 
Damn, I thought that might be the case but I've never used ImageSegments myself 
so I figured I'd bounce the 
idea off you guys.  Any other ideas for rolling out upgrades to a farm smoothly 
without killing sessions?

Original comment by ramon.l...@gmail.com on 13 Jul 2008 at 5:22

GoogleCodeExporter commented 9 years ago 
But what if it doesn't? Even if it doesn't work for 5% of the cases it would 
still 
be useful for the 95% other cases.

Original comment by philippe...@gmail.com on 13 Jul 2008 at 5:44

GoogleCodeExporter commented 9 years ago 
@philippe: I don't think it works even in even 1% of the cases, but I've never 
tried it. Furthermore this is 
problematic because the model (and the methods referenced from the callbacks) 
potentially change in code 
updates.

@ramon: Live updates in a load balanced environment are easy. The new images 
are started and added into the 
load balancer. The old ones are configured not to take new sessions anymore, 
but continue to serve the existing 
sessions until the last one expired.

Original comment by renggli on 13 Jul 2008 at 6:22

GoogleCodeExporter commented 9 years ago 
That sounds all fine and dandy, but I  haven't found a way to make Apache's 
mod_proxy_balancer be able to do 
that, and it'd also require bringing the new images online on dynamically 
rotating ports which messes with my 
static daemontools run scripts that run my images as services.

Are you actually doing this anywhere? Using mod_proxy_balancer?  If so, mind 
sharing?

Original comment by ramon.l...@gmail.com on 13 Jul 2008 at 6:32

GoogleCodeExporter commented 9 years ago 
I know of at least 4 productive sites that use this idea. In 3 of those I have 
been personally involved. All these 
setups use mod_rewrite to do the proxying. This is one of the reasons why I am 
so fond of mod_rewrite. 
mod_proxy_balancer is simply not powerful enough to do something like that. All 
these instances use daemontools to start and stop images.

Original comment by renggli on 13 Jul 2008 at 7:48

GoogleCodeExporter commented 9 years ago 
OK, so how about sharing or blogging about how to do such a setup so we can all 
benefit?  This kind of stuff is 
crutial to running a big Seaside site and we shouldn't all have to reinvent the 
wheel, especially if you've already 
done it a couple of times.

Original comment by ramon.l...@gmail.com on 13 Jul 2008 at 7:58

GoogleCodeExporter commented 9 years ago 
There will be a chapter on deployment in the upcoming Seaside book. I don't 
know yet, if this goes that far 
though.

Original comment by renggli on 13 Jul 2008 at 8:08

GoogleCodeExporter commented 9 years ago 
OK, maybe I'm not being clear enough.  That's great that it might be in the 
Seaside book when it eventually 
comes out, but this is a bug problem for me *right now* and I could really use 
a solution *yesterday*.  Even if 
you won't share it publicly, is this solution something you'd be willing to 
share privately maybe?  Rolling out new 
code is a real hassle for me right now and this would greatly ease my pain.

Original comment by ramon.l...@gmail.com on 13 Jul 2008 at 8:24

GoogleCodeExporter commented 9 years ago 
This is not something that can be demonstrated by posting a few lines of a 
configuration file. Depending on your 
exact requirements a solution might end up quite different and involve several 
scripts and additions to your 
images. It is no rocket-science, but it is certainly not something you just 
find somewhere ready-made and for 
free.

Original comment by renggli on 13 Jul 2008 at 8:47

GoogleCodeExporter commented 9 years ago 
OK, I can understand that, a consultant has to make a living after all.  I see 
if I can't hack something up myself, 
thought now that I know it's done with rewrite rules I can envision a 
rewritemap and a few scripts getting me 
down the right path.  Thanks for the tip, I guess mod_proxy_balancer wasn't the 
solution I thought it was.

Original comment by ramon.l...@gmail.com on 13 Jul 2008 at 9:14