[Glass] [ANN] GsUpgrader

Wed Sep 24 12:16:03 PDT 2014

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 <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> On Mon, Sep 22, 2014 at 12:01 PM, Jon Paynter <kittle31 at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140924/81e95453/attachment.html>