Deploying with GsDeployer

We're using something like the following line of code to deploy GLASS code:

        GsDeployer deploy: [(ConfigurationOfCupertino project latestVersion: #baseline) load].

This works great, most of the time. But occasionally, deployment fails after loading the code but before the auto-migrate has done its work. I haven't kept great notes, but most recently it happened when the maintenance gem was in the middle of a long-running MFC. My gem couldn't get the gcLock.

It hasn't happened very often, but it's made a mess when it has. In this most recent episode, I was upgrading Seaside to 3.0.7 and I ended up with multiple WAFileLibrary classes, one of which was not a new version of the other.

So, my questions are:

1. Any way to tell if the gcLock is available before I start trying to do a big code load?

2. Could this somehow be incorporated into GsDeployer? I like the way the system tries to grab the lock and bails out if it can't get it in 2 minutes, I just don't like the effect of its bailing out so late in the process.

3. Somewhat related: should I be using bulkMigrate: instead of deploy:? It looks safe, and I like the idea of saving time on listInstances: invocations. I've also had the normal auto-migration fail me once when I pushed an inst var up to a superclass, since apparently the subclass got re-defined before the superclass did. Would bulk-migrating have dodged this?

Thanks,

--
Ken Treis
Miriam Technologies, Inc.

----- Original Message -----
| From: "Ken Treis" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Friday, May 18, 2012 12:24:04 PM
| Subject: [GS/SS Beta] Deploying with GsDeployer
|
| We're using something like the following line of code to deploy GLASS
| code:
|
| GsDeployer deploy: [(ConfigurationOfCupertino project latestVersion:
| #baseline) load].
|
| This works great, most of the time. But occasionally, deployment
| fails after loading the code but before the auto-migrate has done
| its work. I haven't kept great notes, but most recently it happened
| when the maintenance gem was in the middle of a long-running MFC. My
| gem couldn't get the gcLock.
|
| It hasn't happened very often, but it's made a mess when it has. In
| this most recent episode, I was upgrading Seaside to 3.0.7 and I
| ended up with multiple WAFileLibrary classes, one of which was not a
| new version of the other.
|
| So, my questions are:
|
| 1. Any way to tell if the gcLock is available before I start trying
| to do a big code load?

You can attempt to acquire the gcLock yourself (System>>_lockGc:) ... you'll get a String back (with reason lock not acquired) or true, but you have to release the lock before you call listInstances ... it's not easy to make the happen in the autoMigration case, because it's hard to tell if you already have the lock and is probably overkill for the general case ... you could arrange to release the lock in GsDeloyer when doing bulkMigrate: (release lock before calling listInstances and reacquire after listInstances returns). There is the potential for a race in there, but the window is significantly smaller ...

I'm going to submit a glass bug for me to add this logic to the standard GsDeployer code and an internal bug, to make sure the internal engineers are aware of the issue.

|
| 2. Could this somehow be incorporated into GsDeployer? I like the way
| the system tries to grab the lock and bails out if it can't get it
| in 2 minutes, I just don't like the effect of its bailing out so
| late in the process.

Yeah, that's the kind of logic I'd throw in for my implementation.

|
| 3. Somewhat related: should I be using bulkMigrate: instead of
| deploy:? It looks safe, and I like the idea of saving time on
| listInstances: invocations. I've also had the normal auto-migration
| fail me once when I pushed an inst var up to a superclass, since
| apparently the subclass got re-defined before the superclass did.
| Would bulk-migrating have dodged this?

bulkMigrate can be used in most cases as long as you're aware of a couple of the limitations:

  1. any initialization methods that are fired during the Monticello
     load may not have the desired effect since instances haven't been
     migrated yet.
  2. bulkMigrate can't be used if changes are made to classes with instances on
     the stack. Uupdating Monticello and Metacello are the big exposure here, but
     it's difficult to know whether or not a Monticello or Metacello upgrade
     will be triggered, otherwise I would recommend it's use.

For production upgrades, you are likely to know exactly what you are upgrading and probably even done a test or two beforehand, so you can have a pretty good idea of whether the bulkMigrate: can be used ...

Thanks for the report,

Dale