[Glass] Is it ok to directly kill seaside gems to stop?

[Mariano Martinez Peck]

On Thu, Dec 19, 2013 at 5:32 PM, Dale K. Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> `kill` is not going to allow any Smalltalk cleanup code to run, but we do
> do a certain amount of graceful gemstone shutdown when the gem/topaz
> receives a `kill` signal ... there is no real equivalent to the
> shutDownList: in GemStone ... there is a startUpList: that is honored on
> session login, but startup: should really only be used to set up session
> temps ... changing persistent state on startup is something to think twice
> about ...
>
> Of course in gem, the only interesting state is persistent state, so the
> amount of cleanup needed is minimal ... you always start from the state of
> the last commit regardless of how the system shut down ...
>
> BTW, even the stoned process will shut down gracefully on a `kill` ... one
> of our QA processes randomly kills gemstone processes (I think one variant
> even uses `kill -9`) to harden the system ... keep in mind that `kill -9`
> on an actively running stone should not introduce corruption, but you might
> have to restore from logs to get running again ... a straight `kill` of the
> stone should not require a restore from logs ... with emphasis on "should
> not"
>
>
This is perfect clear! Thanks dale for the explanation.





> Dale
> ------------------------------
>
> *From: *"Mariano Martinez Peck" <marianopeck at gmail.com>
> *To: *"Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
> *Cc: *glass at lists.gemtalksystems.com
> *Sent: *Thursday, December 19, 2013 12:01:25 PM
> *Subject: *Re: [Glass] Is it ok to directly kill seaside gems to stop?
>
>
>
>
>
> On Thu, Dec 19, 2013 at 4:55 PM, Dale K. Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> It is safe to use `kill` on  topaz, gems, and stoned ... you can use
>> `kill -9` but you risk a non-clean shutdown of the process. It is sorta
>> safe to use `kill -9` on a topaz or gemtools gem. `kill -9` can also be
>> used on the stone process but only when a `kill` is not working (look in
>> the stone log for clues) ... if you kill -9 a stoned process you might have
>> recover form tranlogs ... after using `kill -9` you will want to check the
>> status of shared memory and if there are shared memory segments hanging
>> around there may be some additional gemstone processes still "alive" and
>> they should be killed ... and if the shared memory is still around you can
>> remove the shared memory segment ...
>>
>> Do not kill the "cache" process (from gslist) ... this is the process
>> that should clean up the SPC ... if you kill this guy then you will
>> definitely clean up the shared memory segments ...
>>
>>
> But then I am right that #close is not being send to web adaptors when we
> stop the seaside gems using WAGemStoneRunSeasideGems. So if adaptors need
> to do some external cleanings or something (inside #close) then sending
> kill wouldn't be bad? And what about the shutdown list? and ......
> Maybe the gem can catch the kill signal and perform that as Pharo's
> "Smalltalk snapshot: false andQuit: true" ?
> or maybe you don't care at all because the session won't be committed?
>
> Thanks for the clarification!
>
>
>
>
>
>> Dale
>> ------------------------------
>>
>> *From: *"Mariano Martinez Peck" <marianopeck at gmail.com>
>> *To: *glass at lists.gemtalksystems.com
>> *Sent: *Thursday, December 19, 2013 11:38:52 AM
>> *Subject: *[Glass] Is it ok to directly kill seaside gems to stop?
>>
>>
>> Hi guys,
>>
>> If I understand right, the stop in runSeasideGems30 simply sends a kill
>> to the gem. But...this wouldn't allow a proper clean up of web adaptors or
>> anything (like the typical #stop).
>> Is this ok?...
>>
>> Thanks,
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131219/b343f5c5/attachment-0001.html>