Hi -
[Apologies for the cross-post but there may be answers to this question coming from people who are subscribed to Seaside but not Squeak-dev] What are the best practices for upgrading portions of your running server? I'm not talking about replacing the main business logic of your server application but rather relatively small things like an improved log module, or an administrative report function etc. Basically parts that you can assume aren't used while you upgrade them. I was quite surprised that I wasn't able to find any recommendations on how to do that. And I can't imagine that this problem hasn't come up in Seaside or other Squeak or Smalltalk server deployments. So what do people do in such a situation? Fire up VNC and load the latest MC package? Is that feasible when you have hundreds of users pounding the server? Any other (semi- or fully-) automated variants? Alternative recommendations? Thanks for any insights you can share. Cheers, - Andreas _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Well, I can only say that I've updated (without restarting) a handful of
images that were running either Seaside or something else using Kom and have not had any troubles. In most cases these were images that were probably not getting but a few hits a minute, but I believe in at least one case we made changes to Swiki (yes, wiki.squeak.org) and had no trouble. Those were very minor changes though if I remember correctly (just a method or two). Ken On Wed, 2008-04-02 at 09:28 -0700, Andreas Raab wrote: > Hi - > > [Apologies for the cross-post but there may be answers to this question > coming from people who are subscribed to Seaside but not Squeak-dev] > > What are the best practices for upgrading portions of your running > server? I'm not talking about replacing the main business logic of your > server application but rather relatively small things like an improved > log module, or an administrative report function etc. Basically parts > that you can assume aren't used while you upgrade them. > > I was quite surprised that I wasn't able to find any recommendations on > how to do that. And I can't imagine that this problem hasn't come up in > Seaside or other Squeak or Smalltalk server deployments. So what do > people do in such a situation? Fire up VNC and load the latest MC > package? Is that feasible when you have hundreds of users pounding the > server? Any other (semi- or fully-) automated variants? Alternative > recommendations? > > Thanks for any insights you can share. > > Cheers, > - Andreas > > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside signature.asc (196 bytes) Download Attachment |
Hi,
Check out Ramon's Blog post, which can guide you, though I havent used them. http://onsmalltalk.com/programming/smalltalk/upgrading-a-running-squeak-image/ http://onsmalltalk.com/programming/smalltalk/simple-file-based-application-configuration/ HTH, Rajeev On Wed, Apr 2, 2008 at 10:29 PM, Ken Causey <[hidden email]> wrote: Well, I can only say that I've updated (without restarting) a handful of -- Rajeev Lochan Co-founder, AR-CAD.com http://www.ar-cad.com +91 9243468076 (Bangalore) 080 65355873 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Excellent links, thanks a lot (and to Ramon for writing the blog).
Interestingly, the issue of configuration management was one of the ones that I've been thinking about recently too ;-) Cheers, - Andreas Rajeev Lochan wrote: > Hi, > Check out Ramon's Blog post, which can guide you, though I havent used them. > > http://onsmalltalk.com/programming/smalltalk/upgrading-a-running-squeak-image/ > > http://onsmalltalk.com/programming/smalltalk/simple-file-based-application-configuration/ > > HTH, > Rajeev > > On Wed, Apr 2, 2008 at 10:29 PM, Ken Causey <[hidden email] > <mailto:[hidden email]>> wrote: > > Well, I can only say that I've updated (without restarting) a handful of > images that were running either Seaside or something else using Kom and > have not had any troubles. In most cases these were images that were > probably not getting but a few hits a minute, but I believe in at least > one case we made changes to Swiki (yes, wiki.squeak.org > <http://wiki.squeak.org>) and had no > trouble. Those were very minor changes though if I remember correctly > (just a method or two). > > Ken > > On Wed, 2008-04-02 at 09:28 -0700, Andreas Raab wrote: > > Hi - > > > > [Apologies for the cross-post but there may be answers to this > question > > coming from people who are subscribed to Seaside but not Squeak-dev] > > > > What are the best practices for upgrading portions of your running > > server? I'm not talking about replacing the main business logic > of your > > server application but rather relatively small things like an > improved > > log module, or an administrative report function etc. Basically parts > > that you can assume aren't used while you upgrade them. > > > > I was quite surprised that I wasn't able to find any > recommendations on > > how to do that. And I can't imagine that this problem hasn't come > up in > > Seaside or other Squeak or Smalltalk server deployments. So what do > > people do in such a situation? Fire up VNC and load the latest MC > > package? Is that feasible when you have hundreds of users > pounding the > > server? Any other (semi- or fully-) automated variants? Alternative > > recommendations? > > > > Thanks for any insights you can share. > > > > Cheers, > > - Andreas > > > > > > _______________________________________________ > seaside mailing list > [hidden email] > <mailto:[hidden email]> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > -- > Rajeev Lochan > > Co-founder, AR-CAD.com > > http://www.ar-cad.com > +91 9243468076 (Bangalore) > 080 65355873 seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
If I understand what DabbleDB does, they essentially give each user their own squeak process to run in. When a session is first established, they start up a new image. Upgrading would be a matter of dropping a new image somewhere and as old sessions expire and new ones created, users are migrated over to the new code. With hydraVM, a scheme like that might be doable with just a small bit of session management in the main image.
(with swiki.net, I used to VNC in (I ran squeak headful in a regular VNC session...at the time, the squeak VNC server didn't exist), fix bugs or load code on the fly, but I was always a bit nervous about a slip of the mouse or a mistake taking the whole thing down...I would make changes in a way that they were captured and repeatable (using change sets (this was pre-MC)) and then re-apply the changes to a clean image on disk...I didn't like snapshotting with all the session related state bloating the image) - Stephen On Wed, Apr 2, 2008 at 9:23 PM, Andreas Raab <[hidden email]> wrote: Excellent links, thanks a lot (and to Ramon for writing the blog). Interestingly, the issue of configuration management was one of the ones that I've been thinking about recently too ;-) _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On Thu, Apr 3, 2008 at 12:00 PM, Stephen Pair <[hidden email]> wrote:
> If I understand what DabbleDB does, they essentially give each user their > own squeak process to run in. When a session is first established, they > start up a new image. Upgrading would be a matter of dropping a new image > somewhere and as old sessions expire and new ones created, users are > migrated over to the new code. With hydraVM, a scheme like that might be > doable with just a small bit of session management in the main image. That's more or less right, yes. I've used variations on that strategy before - in general, having multiple images going where old sessions go to the old image but new sessions get routed to the new image makes for very smooth upgrades. Avi _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Avi Bryant wrote:
> On Thu, Apr 3, 2008 at 12:00 PM, Stephen Pair <[hidden email]> wrote: >> If I understand what DabbleDB does, they essentially give each user their >> own squeak process to run in. When a session is first established, they >> start up a new image. Upgrading would be a matter of dropping a new image >> somewhere and as old sessions expire and new ones created, users are >> migrated over to the new code. With hydraVM, a scheme like that might be >> doable with just a small bit of session management in the main image. > > That's more or less right, yes. I've used variations on that strategy > before - in general, having multiple images going where old sessions > go to the old image but new sessions get routed to the new image makes > for very smooth upgrades. Yes, that's what we're doing too. When we need to upgrade a server we simply don't let any new sessions go onto it and once everyone is off the server is up for grabs. Unfortunately, some of the sessions last quite a while (sometimes for several days because our notion of "session" spans multiple users which need to overlap only for a short amount of time) which I guess is good business-wise and we're not running a lot of servers (which I guess is good too, since we scale) but it makes for some rather long delays which could be mitigated by a "hot" (or maybe just "warm") upgrade. Cheers, - Andreas _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |