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

Thu Dec 19 12:32:25 PST 2013

`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 ... 

O f course in gem, the only interesting state is persistent state, so the amount of cleanup needed is minimal ... you a lways 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" 

Dale 
----- Original Message -----

| 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131219/3412fa51/attachment.html>