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

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

Dale

---

From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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

Dale

---

From: "Mariano Martinez Peck" <[hidden email]>

To: "Dale K. Henrichs" <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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" <[hidden email]>
To: [hidden email]
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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--
Mariano
http://marianopeck.wordpress.com