[Glass] [ANN] GsUpgrader

Earlier Johan reported an issue with GsUpgrader[1], where he discovered that a failure during GsUpgrader like the following:

--transcript--'======================'
--transcript--'=====Metacello Preview already loaded'
--transcript--'======================'
--transcript--'=====Upgrading Metacello'
--transcript--'...RETRY->BaselineOfMetacello'
--transcript--'...RETRY->BaselineOfMetacello'
--transcript--'gofer repository error: ''a GoferRepositoryError occurred (error 2710)''...ignoring'
--transcript--'...FAILED->BaselineOfMetacello'
ERROR 2710 , a MetacelloPackageSpecResolutionError occurred (error 2710) (MetacelloPackageSpecResolutionError)
topaz > exec iferr 1 : stk

Could be traced to a fork failure like the following:

ERROR 2201 , a ExternalError occurred (error 2201), reason:hostErrPerform, GemStone cannot execute "'/usr/bin/curl -L https://github.com/dalehenrich/filetree/zipball/gemstone2.4 > /tmp/github-dalehenrichfiletreegemstone24.zip 2> /tmp/curl-tmpgithubdalehenrichfiletreegemstone24zip.err'" on the server OS shell, 'HostPerform failed; errno 12, Cannot allocate memory; command file /var/tmp/fileGDSvTn resultFile /var/tmp/filenfFZYd' errno=12 rawStatus=-1 childStatus=255 (ExternalError)

The fork failure was masked by a bug[2] in the Metacello RETRY code.

Initially I was unable to reproduce the bug, but with the help and patience of Johan we finally determine that the the fork was failing because the virtual machine that Johan was using was configured to have 0k of swap space ... the virtual machines that I was using were all configured to use 1Gb of swap space ...

Johan was using a vm with 4Gb of ram (0k swap space) and 2Gb of SPC ... I reproduced the problem using a vm with 2Gb of ram (0k swap space) and a 1.35Gb SPC ... If I configured a vm with 2Gb of ram (1Gb of swap) and a 1.35Gb SPC I did not hit the fork failure, because linux will use the swap sapce to cover for shortfalls in real memory ...

Until we have better information I will recommend that you run GemStone on systems with  1Gb of swap space to avoid problems ... Presumably one can get a way with less swap space, but I think it is a good idea to to run with some swap space to provide a buffer for when you run yourself out of real memory especially when you are running in Small memory vms ...

GemStone processes do not necessarily allocate all of the memory that they could potentially use (including the SPC), so you can run for long periods of time where the memory that could be potentially allocated by GemStone (including the SPC) exceeds your available RAM and without either additional RAM and/or swap space you are exposed to running out of real memory if the SPC is filled up and/or one or more topaz gems are under memory pressure (things that can happen when running load scripts that do instance migrations because of class shape changes).

I will be fixing the Metacello RETRY code bug, so that the root cause of the load error is exposed, but be prepared for the fact that the root cause of at least some of the GsUpgrade problems may be traced to memory issues ...

Dale

[1] https://github.com/GsDevKit/gsUpgrader/issues/5
[2] https://github.com/dalehenrich/metacello-work/issues/227
[3] https://github.com/GsDevKit/gsUpgrader/issues/5#issuecomment-56719148

On Mon, Sep 22, 2014 at 12:22 PM, Dale Henrichs <[hidden email]> wrote:

On Mon, Sep 22, 2014 at 12:01 PM, Jon Paynter <[hidden email]> wrote:

Hi Dale,
Im at the office right now with a fresh VM.  No dev work was done, so I removed /opt/gemstone to start over.

Here are the steps I took

1)  ./installGemstone.sh 3.1.0.6

   note - since outbound FTP is blocked, I manually transferred the zip file to my VM.

2) startnet / startGemstone

3) load GsUpgrader

4) run #upgradeGLASS1

.... which worked.

Except when I connect with my pharo dev image, there are no Seaside classes loaded -- WAComponent does not exist.

So im puzzled as to what actually got "upgraded"

GsUpgrader does not install or upgrade Seaside ... GsUpgrade upgrades GLASS/GLASS1, Grease and Metacello ...

A virgin 3.1.0.6 (extent0.seaside.dbf) does not have the latest Grease, Metacello or GLASS1 installed so GsUpgrade, upgrades those packages ... Once you've done the upgrade, the install of Seaside should run smoothly ...

Note - the previous version was using gemstone 3.2.2...which may be where my previous problems were coming from.

I am running tests of GsUpgrader against virgin installs from 2.4.4.1, to 3.2.2 and many of the version in between[1] and they are all passing ...

I believe that one set of problems come from attempting to use GsUpgrader in images that have already had some combination of Metacello/GLASS1/Grease installed ... I would like to be able to characterize those types of problems so that I can bullet-proof the GsUpgrader script ... the offset error that you reported this morning helps me to bullet-proof GsUpgrader[2]

Another set of problems is very likely due to the out-of-memory problem reported by Johan ... in fact once I reproduce Johan's problem in my lab, I might start to see the other problems as well ...

Dale

[1] https://travis-ci.org/GsDevKit/gsUpgrader/builds/35778252
[2] https://github.com/GsDevKit/gsUpgrader/issues/6