Connection dies with ECONNREFUSED

[Rambo]

I'm establishing a streaming connection using http.get(). It's supposed to be kept alive forever but suddenly it dies with en ECONNREFUSED error that I cannot catch. 

I know everyone is sick of this type of error but no one says how to solve it. How can I catch that error and what the fuck is that?

node.js:201

        throw e; // process.nextTick error, or 'error' event on first tick

              ^

Error: connect ECONNREFUSED

    at errnoException (net.js:642:11)

    at Object.afterConnect [as oncomplete] (net.js:633:18)

This is the code that actually sends the request:

var options = {

host : 'stream.gnip.com',

port : 443,

path : '/accounts/NiceStream/publishers/twitter/streams/track/prod.json',

headers : {

'Authorization' : basicAuth(username, password),

'Accept-Encoding' : 'gzip'

}

};

var req = https.get(options, function(res) {

var gunzip = zlib.createGunzip();

gunzip.on('data', function(data) {

self.parser.receive(data);

});

gunzip.on('error', function(err) {

self.emit('error', err);

});

res.pipe(gunzip);

res.on('error', function(err) {

self.emit('error', err);

self.end();

});

res.on('end', function() {

self.end();

});

});

req.on('error', function(err) {

self.emit('error', err);

self.end();

});

req.end();

[Diogo Resende]

On Wed, 22 Feb 2012 07:19:33 -0800 (PST), Rambo wrote:
> I'm establishing a streaming connection using http.get(). It's
> supposed to be kept alive forever but suddenly it dies with en
> ECONNREFUSED error that I cannot catch.
> I know everyone is sick of this type of error but no one says how to
> solve it. How can I catch that error and what the fuck is that?

Node version might be helpfull. Perhaps an old bug already
solve on recent versions?

---
Diogo R.

[Rambo]

node v0.6.10

[Rambo]

I'm also experiencing random disconnects without any emitted errors, that's just bizarre. I'm sure the server is not causing the disconnection. What could be happening?

[Jeremy Darling]

OS, Num CPUs, Firewall or no Firewall, etc etc please.  Lots of things can cause a connection to be terminated that are in and out of scope for any application.

As for catching you can use process.on('error') or process.on('exit') or try{}catch(e){} and retry logic depending on where the line is getting cut.

 - Jeremy

On Wed, Feb 22, 2012 at 10:01 AM, Rambo <demi...@gmail.com> wrote:

I'm also experiencing random disconnects without any emitted errors, that's just bizarre. I'm sure the server is not causing the disconnection. What could be happening?

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Demián Andrés Rodriguez]

But the thing is that now the connection ends without emitting any 'error' or 'end' event. I've registered a listener for every damn event the request & response emits, what am I missing?

We are not behind a firewall:

root@w5:/var/www/nsnode# lscpu

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

CPU(s):                16

Thread(s) per core:    2

Core(s) per socket:    4

CPU socket(s):         2

NUMA node(s):          2

Vendor ID:             GenuineIntel

CPU family:            6

Model:                 44

Stepping:              2

CPU MHz:               2399.956

Virtualization:        VT-x

L1d cache:             32K

L1i cache:             32K

L2 cache:              256K

L3 cache:              12288K

[Mikeal Rogers]

Your original error looks to be thrown **before** the HTTP client attaches it's error listener.

This is kind of insane because as soon as a socket is created it is assigned using ClientRequest.onSocket() and in a nextTick() handler it adds the error listener. The socket's nextTick() handler for this error is added before the nextTick() handler ClientRequest has BUT we shouldn't be getting network errors without a full cycle through the event loop.

Has something changed in libuv that would allow us to get an ECONNREFUSED event before nextTick() handlers fire when the object is created?

The "random disconnects" is another issue, if it is as issue at all. Node will disconnect sockets to the remote server when they are not in use. If this happens cleanly between HTTP requests there will be no error.

-Mikeal

On Feb 22, 2012, at February 22, 20128:01 AM, Rambo wrote:

I'm also experiencing random disconnects without any emitted errors, that's just bizarre. I'm sure the server is not causing the disconnection. What could be happening?

[Rambo]

How can the error be happening before the error event attachment if the connection is alive for at least 10 minutes?

Regarding the random disconnects, maybe there is no error but what about the 'end' event that ClientResponse should emit? I've registered a listener for that event but nothing gets called!

Could be something related to gunzip? out of memory? cache full? wtf? 

[Jeremy Darling]

Notice I said process.on('error') and process.on('exit') NOT connection.on(*).  If this is something that is happening lower than the socket level you may not be able to catch it at the socket level.  Since your getting an ECONREFUSED error after the socket is stableized (sp?) and running I'd see if I couldn't catch the app error instead.

BTW: Are you using any IPC stuff in your code, if so you may be chasing the wrong crash?  I've had that same error come from Hook's (unrelated I'm sure) when trying to use fork instead of spawn.

 - Jeremy

[Ben Noordhuis]

If it's reproducible and if you can somehow turn it into a
ready-to-run test case, please open a bug report.

[Demián Andrés Rodriguez]

I would need access to a public streaming api that uses gzip! I cannot publish the auth details.

[Mikeal Rogers]

On Feb 22, 2012, at February 22, 201211:43 AM, Rambo wrote:

How can the error be happening before the error event attachment if the connection is alive for at least 10 minutes?

Regarding the random disconnects, maybe there is no error but what about the 'end' event that ClientResponse should emit? I've registered a listener for that event but nothing gets called!

If the connection dies before ClientResponse emit's end then there will be an error event. A disconnect in the middle of the response is considered an error.

Could be something related to gunzip? out of memory? cache full? wtf? 

nope, none of those things would cause this.

[Mikeal Rogers]

You can create a node.js streaming gzip http server and connect to it in node within a single test file. If you can reproduce the problem with a single node script then there is a 100% chance it will get fixed.

[Ben Noordhuis]

On Sun, Jul 8, 2012 at 10:00 PM, Frederik Berg <allyou...@gmail.com> wrote:
> I got the same error with node.js 0.8 (on windows 7 64 bit if it matters)
>
> And... I wrote some small script that does not fail to throw the error:
>
>>> var net = require('net');
>>>
>>> var connection;
>>>
>>>
>>> try{
>>>
>>> connection = net.connect({'port':6667,'host':'freenode.net'},function ()
>>> {
>>>
>>> console.log('connection open');
>>>
>>> });
>>>
>>> connection.setEncoding('utf8');
>>>
>>> connection.on('data', function (data) {
>>>
>>> console.dir(data);
>>>
>>> });
>>>
>>> connection.on('end', function () {
>>>
>>> console.log('irc conenction closed');
>>>
>>> });
>>>
>>> }catch(err){
>>>
>>> console.log('error: '+err);
>>>
>>> }
>
>
> it does give
>>>
>>> C:\some\path>node test.js
>>>
>>>
>>> events.js:66
>>>
>>> throw arguments[1]; // Unhandled 'error' event
>>>
>>> ^
>>>
>>> Error: connect ECONNREFUSED
>>>
>>> at errnoException (net.js:781:11)
>>>
>>> at Object.afterConnect [as oncomplete] (net.js:772:19)
>>
>>
> If I add:
>>>
>>> process.on('uncaughtException', function(err) {
>>>
>>> console.log(err);
>>>
>>> });
>
> The console logs:
>>
>> { [Error: connect ECONNREFUSED]
>>
>> code: 'ECONNREFUSED',
>>
>> errno: 'ECONNREFUSED',
>>
>> syscall: 'connect' }
>
>
> Now I know that the reason is, that the server is indeed refusing the
> connection but I was wondering...
> why dosn't it catch the error? why is it uncaught, even though it is inside
> a try catch statement?

You're failing to think async. Making the connection, doing the TCP
handshake, etc. are not immediate operations. In short, you need to
add an error listener to your connection object.

[Frederik Berg]

> Now I know that the reason is, that the server is indeed refusing the
> connection but I was wondering...
> why dosn't it catch the error? why is it uncaught, even though it is inside
> a try catch statement?

You're failing to think async. Making the connection, doing the TCP
handshake, etc. are not immediate operations. In short, you need to
add an error listener to your connection object.

works like a charm

did I miss the section where all events that a net.connection can throw in the documentation or is it just missing?

(or am I the only one not instinctively knowing it has exactly 4 namely data,connection,error and end ?) 

[mscdex]

On Jul 9, 10:46 am, Frederik Berg <allyounee...@gmail.com> wrote:
> did I miss the section where all events that a net.connection can throw in
> the documentation or is it just missing?
> (or am I the only one not instinctively knowing it has exactly 4 namely
> data,connection,error and end ?)

http://nodejs.org/docs/v0.8.2/api/net.html#net_event_error_1

[mscdex]

Additionally, the 'error' event is a special one. If you don't add a
listener for it and an async error occurs, the default action is for
the process to die with stack trace output. The same can be said for
the process object's 'uncaughtException' event.