I have read so far that on an uncaught exception it is best to restart the node.js server. However my concern is that for example when multiple users are using the same node.js server and an exception is thrown for one user's request the server would shutdown thus ending whatever processes was taking place for other users. An example would be when one user is in the middle of a critical transaction an uncaught exception is thrown for another user thus stopping the server and having the transaction incomplete and not rolled back somehow even.
In this case considering multiple users what is the best way/practice of handling exceptions
Regards,
MilindaD
process on uncaught exception does not restart the server, it allows Node to continue execution, so the other users will continue any transaction or handling as if nothing happened. Be careful with this method, though, you may use it but the code will be in an unknown state and it will continue execution from where it threw the error.
Related
I have a fairly simple NodeJs server script, that handles incoming data and persists it to a database. The script runs indefinitely. Mostly this works great, but sometimes an error arrises. Is there a way to listen for an exception and if the script was terminated to rerun it again?
(I know the issues for causing the exception must be fixed, and I've done that, but I want to be sure the script always runs as I otherwise loose valuable data; the use case lies in processing IoT sensor data)
It seems like you have an uncaught exception that causes your application to crash.
First of all, you should use try...catch statements to catch exceptions where they can appear within your range of responsibilities. If you don't care about proper error handling and just want to make sure the application keeps running, it is as simple as the following. This way, errors won't bubble up becoming uncaught exceptions to crash your application:
try {
// logic prone to errors
} catch (error) {}
If your application somehow can come into an erroneous state which is unpredictable and hard to resolve during runtime, you can use solutions like process managers, PM2 for instance, to automatically restart your application in case of errors.
Different users trying to access different application routes with heavy manipulation of data. At the mid time one of the request failed due to internal server error and my whole application has been crashed. Thats why other request has been failed because build has been crashed. Is there any solution to handle this situation?
If your program has thrown an uncaught error and crashed then there's nothing you can really do other than start it back up again. You could use something like pm2 to automatically restart your node process when it crashes, and then at least future requests that come in should work (although you will lose any in memory data from before the last crash).
Another thing that I think would help you would be to move your backend onto a serverless architecture where each invocation of your code is independent of the others.
And of course try to fix the code so that it handles things gracefully and doesn't actually throw errors. :)
I'm currently creating a continous webjob that will do polling to an API, and then forward messages to an Azure Service Bus. I've managed to get this to work just fine, but I have one problem; what if my app crashes for whatever reason? What if there's an uncaught exception, or something goes wrong, and the app stops running. How do i get it to run again?
I created a test app, which will send a message every to the Service Bus, then on the 11th message it will crash due to an intentionally placed NullReferenceException. I did this in order to investigate behaviour whenever/if the app crashes.
What happens is that the app runs just fine for the first 10 seconds (as expected). Messages are being sent, and everything looks good. Then after the 10th second, when the exception occurs, nothing happens. No log in Azure saying there was an exception, no reboot - nothing. It just stands there as "running", but messages are no longer being sent.
How do I deal with this? It's essential that the application is able to reboot if it fails. Are there any standard ways to do this? Best practices?
Any help would be appreciated :)
It is always good to handle most of the failure scenarios in the system by ourselves rather than to let the hosting environment to react for the failures.
My suggestion would be to have a check in the code for exceptions like any try catch block in your executable script to catch different kind of failure scenarios and instead of throwing the exceptions, log it your self or take any retry operation if required.
Example, when you got a junk data to process and it failed. Then you can try to do the operation again for eg. 3 times and then finally push a log to deadletter account to manually take care of such junk inputs. And don't let the flow be stopped by throwing the exception but instead handle it your self by logging a message which needs manual intervention.
In any GUI or Web applications, if there is an exception then the flow is re initiated by user click and system will respond. But here as it a background processor, it is ideal to avoid all such control flow blockers.
Hope this would help.
Nodejs's default behavior is to shut down when an error makes it to the main event loop. The manual strongly recommends not overriding this behavior (for instance, via process.on('uncaughtException).
The explanation given is:
An unhandled exception means your application - and by extension
node.js itself - is in an undefined state. Blindly resuming means
anything could happen.
Think of resuming as pulling the power cord when you are upgrading
your system. Nine out of ten times nothing happens - but the 10th
time, your system is bust.
Can someone elaborate on this? Chrome, which uses the same V8 engine as node, resumes its event loop after an uncaught error by default, and AFAIK this doesn't cause any problems. So it doesn't seem like there's any intrinsic reason that V8 can't recover gracefully from an uncaught exception. Is there something in the node internals that behaves differently than Chrome?
The answer does not have anything to do with the engine's ability to restart itself.
It has to do with your own application code. If an unhandled exception occurs, then there is inherently no way of understanding your application's state. If there were, then it would not have been an unhandled exception. And, if you do not know your state, then you cannot be sure that more unhandled exceptions will not continue to occur, most likely causing worse-and-worse issues as time progresses (as unexpected states cascade into more-and-more unexpected states).
Imagine this as code that is running on the server (as it is not at all specific to node.js):
start process
open two server sockets
process incoming requests
If you were to fail to open the second server socket without handling the exception, then chances are your application will not work. Restarting the thread at the next logical step would likely fail to work properly as well. Restarting the engine could not reasonably close the one socket, and it would be unlikely to fix the cause of the second failure (most likely the port is already in use), and if it did close the successfully opened socket, then it had better restart the application so that it can be reopened (or else it made it worse).
That is perhaps an obvious case, but now imagine that you are a graphics application (e.g., a game):
start process
load models
handle state (until closing)
draw screen
If any model failed to load without exception handling, then the process cannot reasonably continue because it will simply cause more errors while drawing.
There are cases where recovering from unhandled exceptions is reasonable. In most client side GUI frameworks there is a way to register for unhandled exceptions, which allows the restarting of the event thread (GUI thread), analogous to Chrome's V8 recovery. It is dangerous because recovery is not guaranteed; whatever caused the unhandled exception could still be in memory and ready to cause the exception again on the next usage of it. However, it's also possible that a well developed application can be small enough to wipe itself clean given such exceptions. The best use of such handlers (handling of unhandled exceptions) is to log the exception so that the issue can be fixed.
To put it differently: imagine an exception occurs that you did not handle in your application anywhere. What can you do to fix it so that it does not happen on the very next pass of the code? To safely answer that implies that you know what caused it, which means that A) it should not be unhandled and B) it is isolated.
The only guaranteed safe reset is to start from the very beginning, which means to restart the application.
In the article about node's domains, they say I should not ignore errors -
"The better approach is send an error response to the request that
triggered the error, while letting the others finish in their normal
time, and stop listening for new requests in that worker."
So my question is, on what types of errors should I close the process:
Should I close the process on any error?
what If the error is not part of the req/res cycle - should I still close the process? let's say I was doing some callculations on data from the DB, and then when saving it again to the DB, I got an error - should I close the process ?
Should I close the process only when I get "uncaught exception" ?
So in general, I would be happy for some general guidelines about when to close a node.js process.
Thanks.
This is something that is primarily about uncaught exceptions.
If your code throws an exception that isn't handled, as a result, some parts of your application may be in an invalid state because the code couldn't finish what it was doing. This is why it's recommended to close/restart processes that do this.
If your process encounters an error which your code handles, then there's no reason to do a restart - you specifically added handling code for the error so that the application does not go into an invalid state and can gracefully handle the error scenario.
So, the answer to the specific question when should you close is when there's an uncaught exception.