[Glass] [ANN] GsUpgrader

[Jon Paynter via Glass]

Nice findings Dale & Johan!

perhaps you can update the installGemstone scripts to print a warning if
they find there is no swap space configured?

On Wed, Sep 24, 2014 at 12:16 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> 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/1150df40/attachment.html>