[Glass] GsDevKit Seaside 3.2.12 problem

[Dale Henrichs via Glass]

On 02/12/2016 09:15 AM, dario.trussardi at tiscali.it via Glass wrote:
> Ciao,
>
>     i work with a GsDevKit Seaside 3.2.12 repository, for understand 
> the Tode tools.
>
>     I create a new project entry:
>
>         project entry --baseline=DtrBase 
> --repo=filetree:///opt/git/DTRDevelopment /sys/local/server/projects
>
>     The baseline is right load when i select the project DtrBase 
> baseline menu option.
>
>     After i do the command:    project load DtrBase.
>
>     The system answer the error:
>
>         a MessageNotUnderstood occurred (error 2010), a SmalltalkProxy 
> does not understand #'at:otherwise:'
It would be very useful to have an actual stack ...I am curious who is 
sending #'at:otherwise:' to the SmalltalkProxy.

If you bring up a tODE debugger you can use the `Window > print window` 
menu item to get a stack that you can copy/paste into a message ..

> and become unstable.
>
>     Now when i do the     project list  command or any other tode 
> comand the system answer:
>
> Gci31xErrSType64(GciErrSType64)>>readArgumentsAndExceptionClassUsingStonIn: 
> in Block: [ :ex | self halt ]
> BlockClosure>>cull:
> MethodContext(ContextPart)>>handleSignal: in Block: [ self 
> exceptionHandlerBlock cull: exception ]
> BlockClosure>>ensure:
> MethodContext(ContextPart)>>handleSignal:
> PrimitiveFailed(Exception)>>signal
> PrimitiveFailed class(SelectorException class)>>signalFor:
> ExternalAddress(Object)>>primitiveFailed:
> ExternalAddress(Object)>>primitiveFailed
> ExternalAddress(ByteArray)>>integerAt:size:signed:
> ExternalAddress(ByteArray)>>unsignedByteAt:
> ExternalAddress>>byteAt:
> Gci31xErrSType64(GciErrSType)>>unsignedLongAt:
> Gci31xErrSType64(Gci3xErrSType64)>>argsSize
> Gci31xErrSType64(GciErrSType64)>>readArguments
> Gci31xErrSType64(GciErrSType64)>>initializeUsingSton:session: in 
> Block: [ :ex | ...
> BlockClosure>>cull:
> MethodContext(ContextPart)>>handleSignal: in Block: [ self 
> exceptionHandlerBlock cull: exception ]
> BlockClosure>>ensure:
> MethodContext(ContextPart)>>handleSignal:
> MethodContext(ContextPart)>>handleSignal:
> TDReadingGciErrorArguments(Exception)>>signal
> TDReadingGciErrorArguments class(Exception class)>>signal
> Gci31xErrSType64(GciErrSType64)>>initializeUsingSton:session:
> Gci31xErrSType64 class(GciErrSType64 class)>>library:session:
> Gci64bit32x(GciLibrary)>>getAndClearLastErrorUsingSton:
> TodeSession>>getAndClearLastError
> TDTopezGemStoneClient>>loginUsing:
> TDTopezGemStoneClient>>login
> TDTopezGemStoneClient>>session
Okay this stack is from the tODE client and there is trouble handling a 
GemStone error that is occurring during login ... In the debugger if you 
look at the this frame:

   Gci31xErrSType64(GciErrSType64)>>readArguments

and look at the the `category number message` instance variables, we'll 
have a clue as to what error is happening during login .. there also 
might some information in the gem log itself.
>
>
> I think the problem is because into my baseline for gemstone i load 
> the MockGemstone.g package.
>
> It is a valid consideration ?
Yes, that could very easily be the source of some serious problems, 
since you would be overriding GemStone methods with a pharo mock 
implementation ...
>
> Now when i do:
>     meeting at meeting001:~$ stopStone seaside_3212
> =================
>    GsDevKit script: stopStone seaside_3212
>               path: /opt/GsDevKit_home//bin/stopStone
> =================
>
>
> Error running shell command: 
> '/opt/GsDevKit_home/server/bin/gs/stopGemstone'
> with args:
> STDOUT: '=================
>    GsDevKit GemStone script: stopGemstone
> =================
> cmdLine= stopstone -i seaside_3212 DataCurator swordfish
> --- 12/02/2016 15:47:06.141 CET ---
> stopstone[Info]: GemStone version ''3.2.12''
> stopstone[Info]: initiating ''seaside_3212'' shutdown...
> [Info]: libssl-3.2.12-64.so: loaded
> ERROR: GsCurrentSession >> _initialize has failed
This likely to be the same error message from your failed login from 
earlier ...
> '
> STDERR: stopstone[Error]: Invalid username(DataCurator) or password.
> Error: Shell command: '/opt/GsDevKit_home/server/bin/gs/stopGemstone' 
> failed.
> GsDevKitStopstoneCommandLineHandler class(Object)>>error:
> GsDevKitStopstoneCommandLineHandler 
> class(GsDevKitAbstractCommandLineHandler 
> class)>>runShellCommand:args:noError:
> GsDevKitStopstoneCommandLineHandler(GsDevKitAbstractComman
> ........
>
>
> Question :
>
>     A) How i can stop the wrong stone?
>             I kill the relative process but the gslist report:
>
>         killed  3.2.12    meeting   feb 12 16:05 Stone seaside_3212
>         killed  3.2.12    meeting   feb 09 14:05 Netldi seaside_3212_ldi

`kill <stoned-pid>` should be just fine
>
>
>     B) How i can restore a good repository for restarting the system?
>
>         I have server/stones/seaside_3212/backups/*  but the 
> repository don't start and i can not      bu restore
>
you should also have a 
server/stones/seaside_3212/snapsots/extent0.tode.dbf that you can copy 
into server/stones/seaside_3212/extents/extent0.dbf after the stone 
process is stopped.

If you are manually copying a snapshot you need to do the following two 
things:

   1. delete the tranlogs from the previous stone
       rm -rf server/stones/seaside_3212/tranlogs/*.dbf

   2. start the stone with:
       $GS_HOME/bin/startStone -b -N $stoneName
> C) I do  a seasideCreateStone devkit_3212 3.2.12    and all works fine.
If you use the `-f` option you can recreate a new stone over the top of 
the old stone:

   seasideCreateStone -f devkit_3212 3.2.12

>
>         But how i can define the seasideWebPort ?
>
>         When i   seasideWebServer devkit_3212 --start    it use the 8080

Take a look at `seasideWebServer -h` ... you should be able to redefine 
the port with the following commands:

   seasideWebServer devkit_3212 --stop
   seasideWebServer devkit_3212 --register=swazoo --port=8080

Dale