error starting MaintenanceVM GemServer

[dalehenrich]

@HeSe wrote:

Based on the ZnSeasideNewGemServer implementation I implemented my own non-seaside MaintenanceGemServer. Unfortunately I run into this error:

topaz 1> topaz 1> topaz 1> topaz 1> GemStone Smalltalk Compiler Errors: (GemServerRegistry gemServerNamed: 'OtfaMaintenanceVM') scriptStartServiceOn: instance.

^1 1: [1031] undefined symbol topaz > exec iferr 1 : stack Stack is not active topaz 1> topaz 1> topaz 1> topaz 1> GemStone Smalltalk Compiler Errors: | logEntry | System beginTransaction. (logEntry := ObjectLogEntry fatal: 'OtfaMaintenanceVM_server_instance: topaz exit' object: 'pid: ', (System gemVersionReport at: 'processId') printString) addToLog. (GemServerRegistry gemServerNamed: 'OtfaMaintenanceVM') ifNotNil: [:gemServer | gemServer crashLog add: (instance) asString -> logEntry ].

^1 System commitTransaction. 1: [1031] undefined symbol topaz > exec iferr 1 : stack Stack is not active

Do I understand it right, that one needs to also define a port for a maintenanceGemserver?

[dalehenrich]

@HeSe wrote:

The Port parameter needs to be in string format since the default port of the MaintenanceVM ist defined as 'instance'. I'll provide a fix

[dalehenrich]

I wrote:

Yeah, the port can be anything as it is not used ... this is probably something that can be eventually improved ...

[dalehenrich]

then @HeSe wrote:

Hi Dale,

I have trouble with Jade and filetree here.

I want to provide a fix in zinc and can't export the changes.

I need to change basicServerOn: port in ZnNewGemServer to:

basicServerOn: port "forked by caller"

| znServer | znServer := self serverInstance. znServer port: port asInteger. znServer initializeServerSocket. [ [ self gemServer: [ znServer serverSocket isValid ifTrue: [ znServer serveConnectionsOn: znServer serverSocket ] ] beforeUnwind: [ :ex | ex pass ] ] repeat ] ifCurtailed: [ znServer releaseServerSocket ]

Could I also do this change directly in GitHub or does do I screw up filetree versioning this way?

This fix is part of this issue: https://github.com/dalehenrich/gsApplicationTools/issues/11

Thanks Sebastian

[dalehenrich]

then I wrote:

Sebastian,

I'm looking at this change and I don't think that adding the beforeUnwind: has any effect ... by default the exception is passed. The only reason that you'd use a beforeUnwind: block is that you wanted to handle an exception specially ...

Also I'm interesed in the use case for asInteger ... the port is supposed to be an integer in the first place ... I don't think that I want to allow folks to be passing around strings or floats as the port number ... at least I don't think I want to do that ...

Dale

[dalehenrich]

@HeSe wrote:

Hi Dale,

when you register a Maintenace gem then this is done e.g. like this

MaintenanceVmGemServer register: 'myMaintenanceServerVM'

then this Gemserver will use it's default port

defaultPortOrResourceNameList "no ports for maintenance vm ... single instance of maintenance should be launched"

^ #('instance')

This is a string.

So once the we start this gem the compile error provided in the script startGemServerGem occurs. This is due to the fact that the string "instance" is considered a undeclared temporary or instance variable during the compile process.

This is why I changed the script. But this leads to the problem that now the PORT is sent as a String to the startup routine "basicServerOn:". This is why I added the asInteger ,....

But this only work for this particular GemServer. I think the other implementors of basicServerOn: need also be changed. I am not using Seaside and did jsut find out about that fact... I assume there are some more implementations out there...

I assume it might be best to change the startGemServerGem script so that it can handle both. String and Integer.

Sebastian

[dalehenrich]

thien I wrote:

Yeah, I guess for me the root problem is that the string 'instance' is used .... asInteger presumably doesn't fix the 'instance' guy unless it does something like return 0 ... in which case the defalut port number should be 0 ...

if this works for you, then continue to use it, but I will probably want to solve the issue differently ...

Dale

[dalehenrich]

Regarding the previous comment about beforeUnwind: ... the beforeUnwind: came from my proposed bugfix for issue #29 ... which turns out not to fix the bug, but the ex ex pass in this case was not necessarily the right answer anyway...

[dalehenrich]

Well for better or for worse, I finally saw the original problem and I think I have a good solution ...

[dalehenrich]

looks good