I have a nodeJS project works fine in my local when using
process.on('uncaughtException', function (err) {
console.log('*********some code*************');
});
This snippet of code gets called when any sync or any async Error happens.
But when I put my project to two the other Linux hosts:
Ubuntu 14.04.3 LTS,
Ubuntu 14.04 LTS.
One works fine, but the other never gets called when Error happens and project shutdown directly.
Any suggestions?
I would refer you to the Node.js documentation about using the uncaughtException event correctly.
The most important part is: "It is not safe to resume normal operation after 'uncaughtException'." The code sample you have here shows that you are logging something, but not exiting the process.
It is possible that on your other system that the process is dying due to the exception, perhaps because of a native module that is having a segmentation fault or other process-ending crash.
Consider catching your exceptions at the points where they occur, and using uncaughtException as an event of last resort for logging fatal errors, while handing off to process.exit(1) to end the process with an error code.
Related
We are on CC&B 2.6. We run base process PUPL Payment Upload on 8 threads. Occasionally the process fails on a thread. The other threads run successfully. And when we restart the job, that thread recovers and completes successfully.
The error message shown is:
SQL Error code 000099997 occurred in module CIPPUPFN:HA100 - UPDATE TCTL
Has anyone encountered this?
This problem might have been caused by a bug in the product that handles the interaction of
sessions and the ThreadlocalStorage object. Some session-related state, such
as the map of DBLocalCobolSQLProcessBackend instances was stored on
ThreadlocalStorage, when it should be on FrameworkSession.
If another session is temporarily "pushed" onto ThreadlocalStorage (e.g. via
SessionExecutable>>doInReadOnlySession()) the original session is set aside
but the map of DBLocalCobolSQLProcessBackend was improperly destroyed and could not be restored when the original session was restored.
If a subsequent db-related call from COBOL into Java requires access to an instance of DBLocalCobolSQLProcessBackend, the desired instance was missing and a new, empty one was created, which lead to a NPE in downstream code.
I have the following error with elasticsearch
[remote_transport_exception] [es-0][x.x.x.x:9300][indices:data/write/bulk[s]]
Or
[remote_transport_exception] [es-0][x.x.x.x:9300][indices:data/write/bulk[s][p]]
It seems like it seems that the elasticsearch queue is full
I am using the nodejs lib https://www.npmjs.com/package/elasticsearch and this error occured after calling client.index.
I am using index as a promise into a rabbitmq consumer, the message are not coming more than 8 in the same time.
client.index().then(...)
It seems that the then is called when the update or create is still in queue, i tried to add {wait_for_active_shards: 'all'} but I have the same issue.
It was an issue because the elasticsearch server was too busy.
I added a retry system in case of 429 error code, now it works fine
I have been using VS code for a bit and suddenly, today, it starter to behave strangely when I debug...
in the debug condole it says
Debugging with inspector protocol because Node.js v8.9.1 was detected.
node --inspect-brk=3193 app.js
Debugger listening on ws://127.0.0.1:3193/c89636e0-f77a-40ab-9046-da1ddaaaf31c
and is keep stopping and looping on a specific function without me having put any breakpoint:
function createScript(code, options) {
return new Script(code, options);
}
I don't know if I have deleted or modified by mistake anything.....
interesting enough if I run the code in the console, it runs without trowing errors... while with the debug it seems I cannot finish the debugging (keep looping)...
I noticed in the debug console the message above.... not sure if that is normal....
any suggestion???
thanks all
Msg told you two things
First one is informational, tells you what protocol it's going with. Inspector is the latest and default protocol.
Second one looping on createScript is a problem. Is it from your own file or a package file?
I have set a node server with Express middleware. I get the ECONNABORTED error randomly on some files when loading an HTML file which triggers about 10 other loads (js, css, etc.). The exact error is:
{ [Error: Request aborted] code: 'ECONNABORTED' }
Generated by this simplified code (after I tried to debug the issue):
res.sendFile(res.locals.physicalUrl,function (err) {
if (err)
console.log(err);
...
}
Many posts talk about this error resulting from not specifying the full path name. That is not the situation here. I do specify the full path and indeed the error is randomly generated. There are times when the page and all its subsequent links load perfectly and there are times when they do not. I tried to flush the cache and did not find any pattern to connect it with this.
This specific error appears to be a a generic term for socket connection getting aborted and is discussed in the context of other applications like FTP.
Having realized that the node worker threads can be increased, I tried to do so using:
process.env.UV_THREADPOOL_SIZE = 20;
However, my understanding is that even absent this, at most the file transfer may have to wait for a worker thread to be free and not get aborted. I am not talking about big files here, all files are less than 1 MB.
I have a gut feeling that this has nothing to do with node directly.
Please point to any other possibilities (node or otherwise) to handle this error. Also, any other indirect solutions? Retrying a few times could be one but that would be clumsy. EDIT: No, I cannot retry. Headers are already sent with the error!
A SIDE NOTE:
Many examples on the use of sendFile skip using the callback thereby giving the impression that it is a synchronous call. It is not. Do use the callback at all times, check for success and only then move on to the "next" middleware or take appropriate steps if the send fails for whatever reason. Not doing so can make it difficult to debug the consequences in an asynchronous environment.
See https://stackoverflow.com/a/36949631/2798152
Could it be possible that in some cases you terminate the connection by calling res.end before the asynchronous call to res.sendFile ends?
If that's not the case - can you pastebin more of your application code?
Uninstalling and Re-installing MongoDB solved this for me.
I was facing the same problem. It started happening when I had to force restart my laptop because it became unresponsive. On restarting, trying to connect to mongo server using nodejs, always threw ECONNABORTED error
What is the best way in node to handle unhandled expections that are coming out of core node code? I have a background process that runs and crawls web content and will run for long periods of time without issue, but every so often an unexpected exception occurs and I can't seem to gracefully handle it. The usual culprit appears to be some networking issue (lost connectivity) where the http calls I'm making fail. All of the functions that I have created follow the pattern of FUNCTION_NAME(error, returned_data), but in the situations where the error occurs I'm not seeing any of the functions I created in the call stack that is printed out, instead its showing some of the core node modules. I'm not really worried about these infrequent errors and their root cause, the purpose of this posting is just trying to find a graceful way of handling these exceptions.
I've tried putting a try/catch at the top level of my code where everything runs under but it doesn't seem to capture these exceptions. Is it good practice in node to use try/catch within all the lower level functions that use any core code? Or is there some way to globally capture all unhandled exceptions?
Thanks
Chris
UPDATED TO ADD STACK
node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: connect Unknown system errno 10060
at errnoException (net.js:642:11)
at Object.afterConnect [as oncomplete] (net.js:633:18)
is there some way to globally capture all unhandled exceptions?
You can catch all exceptions using process.on('uncaughtException'). Listening to this event will avoid the default action of printing the stack and exiting. However be conscious that ignoring exceptions may lead to problems in your app execution.
Link: http://nodejs.org/docs/latest/api/process.html#process_event_uncaughtexception
Pay attention to the documentation advice:
Note that uncaughtException is a very crude mechanism for exception handling. Using try / catch in your program will give you more control over your program's flow. Especially for server programs that are designed to stay running forever, uncaughtException can be a useful safety mechanism.
To catch network errors and avoid the default behavior (printing stack and exit) you have to listen to "error" events.
For example
var net = require('net');
var client = net.connect(80, 'invalid.host', function () {
console.log("Worked");
})
client.on('error', console.log);
I wrote about this recently at http://snmaynard.com/2012/12/21/node-error-handling/. A new feature of node in version 0.8 is domains and allow you to combine all the forms of error handling into one easier manage form. You can read about them in my post and in the docs.
You can use domains to handle callback error arguments, error event emitters and exceptions all in one place. The problem in this specific case is that when you dont handle an error event emitter, node by default will print the stack trace and exit the app.
I've put together a quick error handling file which logs and emails me whenever an unhandled exception is thrown. it then (optionally) tries to restart the server.
Check it out!