Starting Seaside Gems in GS 3.2.8.1

Alejandro,

It sounds like you didn't reload your application code after the upgradeSeasideImage completed - your "application code" includes anything that was loaded on top of GLASS, including running upgradeImage, loading Seaside code and your Seaside application itself ...

I have written an upgradeGemStone script[1] (on the dev branch) for automating the upgrade steps (the script uses a user-specified tODE shell script to load your application code) and you might want to look at the script itself for inspiration ... feel free to ask additional questions.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/bin/upgradeGemStone

On 9/5/15 4:05 PM, Alejandro Zuzek via Glass wrote:

I have just migrated from GS 3.1.0.4 to GS 3.2.8.1 (I followed the procedure,
including running upgradeImage and upgradeSeasideImage scripts). In 3.1.0.4
I would start the Seaside gems with this command:

runSeasideGems30 start WAFastCGIAdaptor "9001 9002 9003"

When I run the same command in the 3.2.8.1 version, the Gems don't start and
in the start logs (for instance in WAFastCGIAdaptor_start-9003.log) I see
this error:

a MessageNotUnderstood occurred (error 2010), a WAGemStoneRunSeasideGems
class does not understand  #'startGemServerOn:'

Furthermore, in the new versión while the class WAGemStoneRunSeasideGems
exists, it doesn't have any methods at all.

In the upgradeSeasideImage output (upgradeTo3x.out) I see many clases being
loaded, but no trace of WAGemStoneRunSeasideGems). The script ended
sucessfully and I don't see any errors in the output log.

Was there a problem in the upgrade of my image or is this intended and there
is now a new procedure to start Seaside gems?

Thanks,

Alejandro



--
View this message in context: http://forum.world.st/Starting-Seaside-Gems-in-GS-3-2-8-1-tp4848347.html
Sent from the GLASS mailing list archive at Nabble.com.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Dale,

I have tried to upgradeSeasideImage two times (both times starting from the same snapshot, where I had just run upgradeImage and I am pretty confident that up to that point everything was going well).

In my first atempt, I ran exactly the same BootstrapApplicationLoadSpecs as in the Example 4.1 in the 3.2.6 install guide. The next time I ran the upgradeSeasideImage script without setting the BootstrapApplicationLoadSpecs at all.

In the upgradeSeasideImage log (upgradeTo3x.out) I see this setion:

Automatically generating list of loaded configuration classes to be removed:
  ConfigurationOfGoferProjectLoader
  ConfigurationOfSeaside30
  ConfigurationOfGsSqueakCommon
  ConfigurationOfGsMonticello
  ConfigurationOfGsFastCGI
  ConfigurationOfGrease
  ConfigurationOfGsCore
  ConfigurationOfMetacello
  ConfigurationOfSwazoo2
  ConfigurationOfGLASS
  ConfigurationOfGsMisc
  ConfigurationOfGofer
  ConfigurationOfGsOB
  ConfigurationOfCarMaintenance

Does this mean that I shoud include a section for each of these Configuration classes in the BootstrapApplicationLoadSpecs and not just the section for ConfigurationOfGLASS? I do see some of these Configuratioin classes in the default bootstrap repository directory ($GEMSTONE/seaside/monticello/repository) but not all. If this is the case, should I also include a section for my own App (ConfigurationOfCarMaintenance)? I am asking this, because I don't have a copy of ConfigurationOfCarMaintenance and its packages locally on the machine where I am upgrading the image and the LoadSpecs appear to expect local directories as repositories.

Thanks for all your patience answering these questions.

Alejandro

On Fri, Sep 11, 2015 at 10:54 PM, Dale Henrichs <[hidden email]> wrote:

Alejandro,

I'm inclined to try to limit the number of variables here ... there are a lot of moving parts involved and I still need to see more detail about how you've upgraded ...

Firstly, what did you use for your BootstrapApplicationLoadSpecs (from Example 4.1 in the 3.2.6 install guide[1]).

set user DataCurator pass swordfish
        login
        run
        UserGlobals
           at: #BootstrapRepositoryDirectory
put: GsPackageLibrary getMonticelloRepositoryDirectory. true
        %
        run
        UserGlobals
           at: #BootstrapApplicationLoadSpecs
           ifAbsent: [
              UserGlobals
                 at: #BootstrapApplicationLoadSpecs
                 put: {{ 'ConfigurationOfGLASS' . '1.0-beta.9.1' .
                        #('default') . BootstrapRepositoryDirectory } . }.
]. true
%
commit
logout 

You should have provided a configuration and version that would ensure that your whole application gets reloaded at the end of the upgradeSeaside script. Getting an MNU makes me think that you haven't arranged to load your entire application into the upgraded image.

Secondly, have you loaded your application code into GS 3.2.8.1 and verified that it works correctly. This is important because it eliminates any variables that might be introduced by the upgrade process and also gives you an assurance that your application should work correctly in 3.2.8.1 ... also you'll have the opportunity to fix any platform specific bugs ...

Dale

[1] https://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-InstallGuide-3.2.6-Linux.pdf

On 9/11/15 5:14 PM, Alejandro Zuzek wrote:

Hi Dale,

I am still unable to make the upgraded image work, that is, I still cannot start the Seaside Gems. I rerun the whole installation process on a backup of my 3.1.0.4 system, including running upgradeImage and upgradeSeasideImage. No errors were reported there, by the WAGemStoneRunSeasideGems class still doesn't understand #'startGemServerOn:

I tried to reload the Seaside Adaptors with this code:

MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
  ConfigurationOfMetacello project updateProject.
  ConfigurationOfMetacello loadLatestVersion.
  Gofer project load: 'Seaside30' group: #('Seaside-Adaptors-FastCGI' 'Seaside-Adaptors-Swazoo').
].

but I get this error:

--transcript--'redirecting to http://seaside.gemtalksystems.com/ss/Seaside30/Seaside-Adaptors-FastCGI-dkh.26.mcz'

--transcript--'Fetched -> Seaside-Adaptors-FastCGI-dkh.26 --- http://seaside.gemstone.com/ss/Seaside30 --- http://seaside.gemstone.com/ss/Seaside30'

ERROR 2718 , a ArgumentError occurred (error 2718), (argument at: 1) contains codePoint 16rd800 not legal for Unicode (ArgumentError)

Is it possible that the .26 version of FastCGI is broken (illegal character?) and that this is preventing upgradeSeasideScript to reload FastCGI code correctly?

Thanks,

Alejandro

On Sun, Sep 6, 2015 at 11:50 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Alejandro,

It sounds like you didn't reload your application code after the upgradeSeasideImage completed - your "application code" includes anything that was loaded on top of GLASS, including running upgradeImage, loading Seaside code and your Seaside application itself ...

I have written an upgradeGemStone script[1] (on the dev branch) for automating the upgrade steps (the script uses a user-specified tODE shell script to load your application code) and you might want to look at the script itself for inspiration ... feel free to ask additional questions.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/bin/upgradeGemStone

On 9/5/15 4:05 PM, Alejandro Zuzek via Glass wrote:

I have just migrated from GS 3.1.0.4 to GS 3.2.8.1 (I followed the procedure,
including running upgradeImage and upgradeSeasideImage scripts). In 3.1.0.4
I would start the Seaside gems with this command:

runSeasideGems30 start WAFastCGIAdaptor "9001 9002 9003"

When I run the same command in the 3.2.8.1 version, the Gems don't start and
in the start logs (for instance in WAFastCGIAdaptor_start-9003.log) I see
this error:

a MessageNotUnderstood occurred (error 2010), a WAGemStoneRunSeasideGems
class does not understand  #'startGemServerOn:'

Furthermore, in the new versión while the class WAGemStoneRunSeasideGems
exists, it doesn't have any methods at all.

In the upgradeSeasideImage output (upgradeTo3x.out) I see many clases being
loaded, but no trace of WAGemStoneRunSeasideGems). The script ended
sucessfully and I don't see any errors in the output log.

Was there a problem in the upgrade of my image or is this intended and there
is now a new procedure to start Seaside gems?

Thanks,

Alejandro



--
View this message in context: http://forum.world.st/Starting-Seaside-Gems-in-GS-3-2-8-1-tp4848347.html
Sent from the GLASS mailing list archive at Nabble.com.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass