Bug? SstWorker can kill itself

[waynej]

We have a server app that is run at a Windows service. When a request comes in from Windows to stop the service, the current process magically calls a specified method which gracefully shuts things down. (Even if the current process is in a 'tight loop' such as "[true] whileTrue" - quite cool) Anyway, part of shutting down is to send #clear to the application context, which results in #shutDown being sent to each SstWorker (such as a Dispatch worker). The problem is that if it was a Dispatch worker that was running when the shutdown came in from Windows, SstWorker>>#shutDown will kill the current process - so our server gets stuck and doesn't exit. Partial stack below.

We've long been running with a patch to prevent the process from killing itself - change the first line of #shutDown to
(process notNil and: [process ~~ Processor activeProcess]) ifTrue: [process terminate].
Is that proper and could be incorporated into an upcoming VA version? Or should we not be shutting down this way?

SstWorker>>#shutDown
receiver = SstWorker(Dispatch worker: 54; available)
[optimized] in SstWorkerManager>>#setupPoolHigh:low:strict:createBlock:destroyBlock:
blockarg1 = SstWorker(Dispatch worker: 54; available)
SstPool>>#primitiveDestroy:
receiver = Pool (in: 1 out: 1)
arg1 = SstWorker(Dispatch worker: 54; available)
[] in SstPool>>#destroyAllElements
receiver = Pool (in: 1 out: 1)
blockarg1 = SstWorker(Dispatch worker: 54; available)
[] in Set>>#do:
receiver = Set(SstWorker(Dispatch worker: 54; available) )
arg1 = [] in SstPool>>#destroyAllElements
blockarg1 = SstWorker(Dispatch worker: 54; available)
Set>>#do:
receiver = Set(SstWorker(Dispatch worker: 54; available) )
arg1 = [] in SstPool>>#destroyAllElements
[] in SstPool>>#destroyAllElements
receiver = Pool (in: 1 out: 1)
blocktemp1 = Set(SstWorker(Dispatch worker: 54; available) )
blocktemp2 = Set(SstWorker(Dispatch worker: 53; available) )
BlockContextTemplate(Block)>>#critical
receiver = [] in SstPool>>#destroyAllElements
SstPool>>#destroyAllElements
receiver = Pool (in: 1 out: 1)
SstPool>>#clear
receiver = Pool (in: 1 out: 1)
[] in SstWorkerManager>>#clear
receiver = a SstWorkerManager
BlockContextTemplate(Block)>>#critical
receiver = [] in SstWorkerManager>>#clear
SstWorkerManager>>#clear
receiver = a SstWorkerManager
SstPooledDispatcher>>#clear
receiver = a SstPooledDispatcher
SstInvocationHandler>>#clear
receiver = SstInvocationHandler(Tcp-Adjustments:/tcp-xx/mymachine:6021)
[optimized] in SstMachine>>#clear
blockarg1 = SstInvocationHandler(Tcp-Adjustments:/tcp-xx/mymachine:6021)
OrderedCollection>>#do:
receiver = OrderedCollection(SstInvocationHandler(Tcp-appName:/tcp-xx/mymachine:6021) )
arg1 = [] in SstMachine>>#clear
SstLocalMachine(SstMachine)>>#clear
receiver = <someName>
SstApplicationContext>>#clear
receiver = SstApplicationContext (anotherName @mymachine:6021)

[wembley]

Wayne -

Couldn't you do something like this?

Code: Select all

[*my magic code to shut everything down] forkAt: userInterruptPriority named: 'Cleanup'

Then the cleanup code is not running on any SstWorker's process.

[waynej]

Yes, that can be done. Thanks for your guidance.

[waynej]

John - it doesn't quite work.

AbtNtServiceInterface>>#stop calls our shutdown code. I can fork our real shutdown work, but would want to wait until that work is done. Once it is done and we return back to #stop, then the image will exit.

However, part of the forked work ends up killing off the SstWorker processes. If that's what happened to be running at the time the stop request came in, then we will never answer back to the #stop method, so we don't exit.

Would you recommend that our forked shutdown work end up doing its own 'System exit'?

Thanks.

[wembley]

Wayne -

I originally thought that the <magic shutdown code> was running in one of the SstWorkers and so when you shutdown all the workers, you shutdown the <magic shutdown code>. So that is the problem I tried to solve.

But now I don't think I understand at all how your code is structured. I don't understand why doing a shutdown on all the SstWorkers causes the <magic shutdown code> not to return to #stop. Where is it hanging?

[waynej]

John, thanks so much for your attention.

Whichever random process is running when the stop thingy comes in, by virtue of the callback we registered, our magic shutdown method is called by AbtNtServiceInterface>>#stop, and once our method answers, the image will exit. All of that takes place on the 'random' process that was running at the time. Our shutdown method does many things including clearing the application context (SstApplicationContext>>#clear) which ends up killing off all the SstWorker processes - Dispatch workers in the example above. The problem is if it is a Dispatch worker that runs this code, it will be one of the Dispatch workers it kills; it kills itself. So the shutting down doesn't answer back to #stop.

So I am simulating the desired effect at the moment by having the now-forked shutting down code do a "System exit".

Is this OK? Or should our shutting down not do things so gracefully. I think our intent is to shut off requests in progress and prevent incoming requests then do whatever else we feel a need to do during shutting down.

[wembley]

Wayne -

OK, now I understand. The #stop method may be running on the process of an SstWorker because it comes in asynchronously. Since the only think the #stop method does after running your code is execute 'System exit', there is no problem with you putting the 'System exit' in your code instead of returning to the #stop method.