We have a number of tasks in a static queue on our server. When the server shuts down (or restarts) we'd prefer not to lose these tasks and therefore we will stash them in a DB structure. On boot this DB structure will be dumped back into the static queue and processing of these queued tasks will continue.
How is it possible to detect a shut down, halt that shutdown, and then continue the shutdown once the above DB storage function has been executed? from what context should this shutdown observation be made?
I'm not sure I understood your question, but if I got it right you want to run some code before your scripts exits to do some kind of cleanup.
You can use process.on(event, handler) to register an exit handler for your script for various events, including exit (the scripts exits), SIGINT (the user Ctrl + Cs the script) and uncaughtException (an exception thrown is not caught). Take a look at this answer.
Related
I want to write an API in Nodejs which will return an error if the excution takes more than a particular time otherwise will proceed normally. How to do that??
Regards,
Abdul
The node thread needs to co-operate by clearing everything that is running on the event loop and then it terminates naturally by returning. So just stop listening for requests, close handles etc. You can use process._getActiveRequests and process._getActiveHandles to see what is keeping the event loop alive.
You can also abruptly interrupt the node thread just by calling OS apis but this will leak a lot of garbage until you exit the process so you cannot start/restart node a lot of times before you need to exit the process anyway to free the leaked resources.
I'm using ServiceStack MQ (ServiceStack.Aws.Sqs.SqsMqServer v4.0.54).
I'm running MQ server inside a Windows Service.
My Goal:
When the Windows service is about to shutdown, I would like to
wait for all running workers to finish processing and then terminate
the MqServer.
Problem:
The ServiceStack MqServer (whether it's Redis/RabbitMq/Sqs) has a Stop() method. But it does not block until all workers complete their work. It merely
pulses the background thread to stop the workers and then it returns.
Then the Windows Service process stops, and existing workers get aborted.
This is the link to github source code -> https://github.com/ServiceStack/ServiceStack/blob/75847c737f9c0cd9f5dd4ea3ae1113dace56cbf2/src/ServiceStack.RabbitMq/RabbitMqServer.cs#L451
Temporary Workaround:
I subclass SqsMqServer, loop through the protected member 'workers' in the base class, and call Stop on each one. (in this case, this Stop() method is implemented correctly as a blocking call. It waits indefinitely until the worker is done with whatever it's currently working on).
Is my current understanding of how to shutdown the MqServer correct? Is this a bug or something I misunderstood.
The source code for SqsMqServer is maintained in the ServiceStack.Aws repository.
The Stop() method pulses the bg thread which StopWorkerThreads() and that goes through and stops all workers.
I work on an application with a REDIS data store. To maintain the data integrity I would like to cleanup the store on process shutdown.
I created a function handler and bind it (with process.on()) to signal events: uncaughtException, SIGINT, SIGTERM, SIGQUIT and it works well (CTRL+C, process killing, exception, ...).
But I've read that in certain conditions the process can exit directly without triggering the other signal events.
The problem in this particular case is that process.on('exit') handler can only process synchronous tasks.
I made different test to try to kill the process in different ways.
And (except with SIGTERM on Windows) I wasn't able to identify the case where process.on('exit') is triggered directly without SIGINT, SIGTERM or other event firing.
So my question is (on Linux system), under what conditions the process can exit directly without firing on of this event: http://nodejs.org/api/all.html#all_signal_events ?
As of now, reading the documentation and doing some research, it seems there is only four way a node.js app exit:
process.exit(), which is handled by process.on('exit')
Receiving a *nix signal, which can be handled by process.on('signal_name')`
Having a exception going back to the event loop, handled by process.on('UncaughtException')
The computer being plugged out, destroyed, the node.js binary blowing up, or a SIGKILL/kill -9, and there is no handling to that.
It usually happen someone don t understand the error message from a uncaughtException, and mistakenly believe it is "something else" that killed node.js.
Indeed. I just meant to point out that Node programs can exit as a result of a signal without having executed a handler (if none was registered). Rereading your post, I see that may be what you meant as well.
Is it possible to create a simple Thread, which runs a SQL statement, and then close the application but let that thread run untill it is finished (main form still closes normally - doesn't wait for thread to finish).
I'm upgrading an application which writes some test data to a log file and I want to bulk insert that log file into a database. Because there is a lot of data and the sql stored procedure which handles it takes a minute or two to complete I've made a thread which runs the stored procedure. This thread is run every so often during the lifetime of the app but now I want to implement so that after the user is finished with testing and closes the app, the rest of the data in the log that isn't on the server yet is synced. This way I can avoid checking logs of previous days if all data is synced.
If I use waitfor function, the whole application won't close untill the stored procedure is finished which is undesirable, because there is nothing the app has to do afterwards. The stored procedure handles all the errors so there is no need to handle errors in the app.
If I remember correctly this is something that is done a lot in linux, a procedure creates another procedure and then ends and the child proc is then orphaned, it is how demons are run. But I have no idea if this is even possible on windows.
A process needs to stay alive until the thread completes. A thread exists in a process. Take away the process and the thread cannot endure.
What you can do is to wait for the thread after the UI has shut down. Put the code that waits for the thread in a method that runs after the UI has closed.
Or, if you want the UI process to terminate before the task completes, that task would have to live in a separate process. You would start a new process to perform the task. That's a lot easier in Unix-like systems which support fork(). Under Windows you'd need to find a way to get the data into the new process.
I'm moving some background processing from an Azure web role to a worker role. My worker needs to do a task every minute or so, possibly spawning off tasks:
while(true){
//start some tasks
Thread.Sleep(60000);
}
Once I deploy, it will start running forever. So later, when I redeploy, how does Azure stop my process for redeployment?
Does it just kill it instantly? Is there a way to get a warning that it's shutting down? Do I just have to make sure everything is transactional?
When a role (either worker or web) is asked to gracefully shut down (because it is being scaled down or because you've asked for a redeployment) the OnStop method of the RoleEntryPoint class is called. This is the same class which has the Run method which likely either contains your loop or calls the code that contains that loop.
A couple of things to note here: The OnStop has 5 minutes to actually stop, after that the process is simply killed. If you have to call something else to shut down asynchronously, you'll need the thread in OnStop to be kept busy waiting until that other process is shut down. Once execution has left OnStop the platform assumes the machine can be shut down.
If you need to gracefully stop processing but it not require a shutdown of the machine then you can put a setting in the service config file that you can update to indicate work should be done or note. So for example a bool that says "ProcessQueues". Then in your onStart in RoleEntryPoint you hook the RoleEnvironmentChanging event. Your event handler then looks for a RoleEnvironmentConfigurationSettingChange to occur and then checks the ProcessQueues bool. If it is true it either starts up or continues processing, if it is false it stop the processing gracefully. You can then do a config change to control when things are running or not. This is one option of handling this and there are many more depending on how quickly you need to stop processing, etc.