-
Notifications
You must be signed in to change notification settings - Fork 390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error: socket hang up in new relic library. #75
Comments
What version of Node are you running, and what version of the agent? There's a problem under node 0.8 and recentish versions of one of the New Relic module's dependencies that causes errors that were being handled one way to turn into unrecoverable crashers. If this isn't crashing your app (and if it is, I apologize, because New Relic tries hard to avoid crashers), are you sure these errors aren't just ordinary failed SSL connection attempts? When you're running the New Relic module, you're going to see Either way, let me know what you find, and thanks for the report! |
This error was occuring to me too. I'm using version 0.10.21 of node. |
@rodrigok, is this causing your app to crash? As I said in my response to @elliotstokes, I'd like to figure out if New Relic is just showing up in the stacktrace (which it's going to do, because of how the module's instrumentation works), or if it's actually either causing problems or turning a recoverable error into a fatal crash. As it stands, I still don't know if there's something here that New Relic needs to fix. |
No, this problem was not cousin my app to crash. |
Thanks! Let us know if you run into situations like this where it causes problems for your app. Waiting to hear back from @elliotstokes before resolving this issue. |
Closing; Elliot hasn't been back since filing it. |
This is happening in my app as well. It doesn't crash my app, but it does clutter my logs with what looks like errors. I am running node v0.8.26, and my log is filled with stuff that looks like this:
Can you provide any advice on what this is? It looks like it is trying to report an inability to send gathered data back to new relic's servers. If these messages are expected in normal operation is there anything that can be done to configure the verbosity? Or is that something that would have to be handled down in that continuation-local-storage module? |
Sorry I haven't been around for the last few weeks. I can confirm that the application does not crash as others have already mentioned. |
I've been seeing this error too, about once a day. We're using node 0.8.7 (though plan to upgrade to 10.latest soon) The app seems to be up during this time, or at least NR doesn't report it as being down (it mostly happens outside of office hours).. |
Hello, everybody! A few responses:
Otherwise, this is all behaving as designed. Thank for the additional details! |
Thank you much for the responses here @othiym23! |
I had another 67 of these errors reported in my control panel this morning - this issue is causing our error rate to spike & NR is emailing us about that, and it's completely outside of our control to fix "behaving as designed" doesn't seem an appropriate resolution to this issue given that |
@spmason Are you sure the errors in your error count are coming from failed connection attempts to New Relic? The logic to talk to our servers lives in a completely different piece of the module that isn't tied to the piece that traces app errors. I agree that if that's happening, it's a bug (and an annoying one!), but looking at the code and our test output, I'm not seeing any evidence that anything like this is what's going on. |
It seems to be coming from the newrelic module:
Also, the Request parameters list the URL as coming from socket.io, but we've set an ignore rule for that URL elsewhere and it's not being reported otherwise - should this even be captured I wonder? |
Right now, New Relic doesn't support SSL between the module and our servers (I'm adding support for that right now!), so that error isn't coming from our code. New Relic does appear in the stack trace, but that's only because of the instrumentation, which more or less guarantees that CLS or the asyncListener (the enabling technologies used by the module) are going to be in every stack trace coming out of an asynchronous callback or event listener. Ignoring rules apply to the socket.io requests, but not to errors, which are always traced unless they're tied to an HTTP status code that you're specifically ignoring. Also, if it seems like the ignoring rule isn't sticking and you're serving your socket.io routes from Express or Restify, you should take a look at using the API call for ignoring transactions instead of using rules – because of how the Express and Restify router introspection work, they override the ignoring rules which are meant for use by developers working without a framework that names their routes. |
Thanks for the explanation(s) @othiym23, that all makes perfect sense. We talk to some downstream server over ssl so it must be those.. Sorry if I wasted anyone's time here, at least if someone else has the same problem this ticket might help them out (or at least not blame you guys!) Thanks again for the help |
…sequelize-app/app/semver-and-newrelic-7.5.3 chore(deps): bump semver and newrelic in /sequelize-app/app
Release v5.1.0
ci: Add Open Source Policy Workflow
ci: Add Open Source Policy Workflow
We appear to be getting this error in our new relic logs that looks like its coming from the new relic library. Below is the stack trace:
The text was updated successfully, but these errors were encountered: