. .


Smalltalk Server Misconceptions

November 29, 2010 6:34:29.000

I've seen this complaint about running Smalltalk app servers before, and I'm sure I'll see it again:

Running headless is a bear. Updating (e.g., loading the latest version of the web server or fixing a security vulnerability) a headless image on a remote server is very difficult (one has to either have a VNC session running in the image or save the image, copy it to a local machine, update it, copy it back, start it up again.)

Well.... not so much. I run a headless server here, and it's pretty easy - I have an image that loads what it needs when it starts up, and I can kill and restart anytime I want. For patching, I simply have a patch directory, and an interface that lets me "poke" the system and load whatever it finds in the patch directory. Since it will only load from there, and only when I tell it too (i.e., there's no code being loaded from an input field), it's secure enough for what I do.

I could automate that more if I felt like it; having a process periodically scan the patch dir, load whatever is there and then delete it would remove a manual step, for instance. The larger point is, patching a running server is easy, and it's one of the truly cool things about running a Smalltalk server.

Those patches vn be very invasive as well - some of the patches I loaded in the past (on the blog I ran at Cincom, which is an ancestor of this one) changed the shape of objects in the image on the fly.

So no, you don't need VNC, or a headful image. All you need is a little planning :)

Technorati Tags: ,

posted by James Robertson


Re: Smalltalk Server Misconceptions

[cees de groot] November 29, 2010 11:59:48.477

I never found VNC much of a burden. For my projects, I always ran the unstripped image under VNC on the server. Helps massively when debugging production issues :)

Re: Smalltalk Server Misconceptions

[James Robertson] November 30, 2010 0:21:37.895

The point is, you don't have to :)

Also, on a server doing a lot of work, live debugging is not always feasible

 Share Tweet This