On the fly modification
Thomas Gagne has some qualms about modifying production Smalltalk images:
Practically speaking, we could probably open a running image, save code, then parcel-out the fixed classes. That would require our production images to be configured to read-in parcels when it starts up. While technically feasibly, it is impractical. We have a distributed application with multiple Smalltalk images running concurrently and each one would have to be re-initialized.
It's simpler than that, IMHO. I modify the running blog server here all the time. I've outlined the steps before, but what the heck - let's go through it again:
- I have a base image that loads all parcels at startup. VW can do that via a command line argument, either with the parcels on the command line or in a config file.
- I have an interface open on the server that allows me to kick it and have it execute specific patches (Smalltalk file-ins)
- I do development on my local Linux box, and export changes in two forms: a file-out of changes, and a new parcel
- I upload the file-out to the patch directory on the server, and the new parcel to the startup directory. I don't worry about saving the image - I just ensure that the latest code is ready to load at startup
- I kick the image so that it loads the patches
That's it. Every major change I've done (including ones that have made shape changes to live objects in the server) has happened on the fly that way. I try not to restart the server, simply to avoid outages.
Technorati Tags: hot loading, live patching
Comments
[Thomas Gagne] November 21, 2006 13:57:43.367
Loading parcels on startup requires the parcels exist in production or that Store repositories be available in production, correct? Saving those parcels requires write permission to wherever the image is configured to load parcels from. Of course, having permission to modify a running image's code is a separate but not trivial problem (I'm typing out loud here).
In production we're currently running a single image as 11 different processes. Think of them as specific programs. The fact they share a common image in a matter of convenience. One of them assists our web server. The other ten are running one of two different programs: five-each of two different programs, all running as server applications behind Message Oriented Middleware. If we were to modify something in any of the server-side applications they same change would be required in the other nine. Granted, we could stop and restart them with updated images but that would defeat the purpose of avoiding restarts.
Because they're separate processes there would have to be some concept of distributing the change across all the running processes--and updating the image (or parcels) as well. That requires some kind of code-sharing or distribution that doesn't exist yet and we're unlikely to pursue ourselves. Even were code shared between the processes (in shared memory) that would not solve the problem for processes ultimately distributed between separate hosts.
James, how many Smalltalk processes are you running? Do you update all of them? One of them? Do you kick all of them? What kind of change-control do you have on your production servers?
Thomas Gagne
Anything Worth Doing
Easy with one, hard with lots
[Mike Hales] November 21, 2006 15:49:11.342
In our app we can load parcels during operation to update and patch. This becomes a difficult problem though when multiple processes are involved. One of our systems typically has a GemStone server and between one and mabye 7 or 8 VW processes distributed on multple machines. Being able to patch on the fly is great, but how do you coordinate that between running and communicating processes. You will have some time when one is patched and the others are not. Depending on the code you are loading this may or may not be acceptable. Sometimes the snychronization mechanism is just shutting down and restarting with the new patches. It is afterall the simplest thing that could possibly work.
Re: On the fly modification
[ James Robertson] November 21, 2006 16:42:58.868
Comment by James Robertson
I only run one image, but if I was running more than one, I would probably implement some simple minded polling scheme - i.e., have every image look in a specific directory once an hour or so. I version all the code in Store, and simply have the latest parcels on the server so that a restart will get the latest code. I run this stuff myself, so I don't have a formal change management process. My process is "when I think it needs an update"
[Isaac Gouy] November 21, 2006 18:08:49.733
When I read it this morning, I felt that this blog entry trivialized (intentionally or not) the situation that Thomas Gagne described, and then quickly repeated a familiar talking point.
James wrote It's simpler than that, IMHO.
Your situation - single server, not a business critical server - is simpler. You didn't speak to the situation Thomas Gagne described.
typical, not difficult
[Arden] November 22, 2006 17:48:59.107
At one shop we had many clients using the application. At startup (a .bat file) it would copy any newer dated parcels to a local location and then launch the app. The app would load several of the parcels, but some were not loaded unless the user chose to run a less frequently run application, then it would load dynamically. If we released new code, we would simply ask the users that needed the new functionality to restart their application. To make that painless, I added a menu option that would shut down their current app, and restart and login to the new app - one click to restart. - Arden