Connection object is null

[domino14]

I see this many times a day in the logs. The relevant snippet of my code looks like this:

sockServer.on('connection', function(conn) {
  console.log(conn);   // This is null sometimes, I don't see how that can be.
  if (_.isNull(conn)) {
    return;
  }
  conn.on('data', function(message) {
    // Let's see what's in this message.
    handleMessage(message, conn);
  });
  conn.on('close', function() {
    channels.manager.removeConnection(conn);
  });
});

server = https.createServer(sslOptions);
sockServer.installHandlers(server, {prefix: '/socket'});
server.listen(9999, '0.0.0.0');

[domino14]

The log message for "null" is always preceded by something that looks like

GET /socket/443/b2j6fxfg/websocket 3ms (unfinished) (if it says unfinished the connection will be null, otherwise, the connection seems to be a full object)

[majek]

"unfinished" means that websockets are actually working (the http connection under websockets is actually "unfinished"). anything else for that url is a wrong answer. Are you sure your load balancer can do websockets?

[tangor86]

I also have that issue but in a very rare cases (2 times on my mind, running server 6-12mo)

// create our server and setup handlers
var echo = sockjs.createServer(sockjs_opts);

echo.on('connection', function(conn) {
    var msg = {};
    conn.channels   = new Array();

Error:

/home/***/node/notif.js:96
        conn.channels   = new Array();
                        ^
TypeError: Cannot set property 'channels' of null
    at Server.<anonymous> (/home/***/node/notif.js:96:18)
    at Server.EventEmitter.emit (events.js:96:17)
    at App.Server.listener [as emit] (/home/***/node/node_modules/sockjs/lib/sockjs.js:182:27)
    at Session.emit_open (/home/***/node/node_modules/sockjs/lib/transport.js:107:23)
    at process.startup.processNextTick.process._tickCallback (node.js:245:9)

System:
Virtual server, "notif.js" running on 80 port,
Linux version 2.6.32-5-amd64 (Debian 2.6.32-41) ([email protected]) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 16:22:28 UTC 2012
Node: v0.8.22
Sockjs:
var sockjs_opts = {sockjs_url: 'http://cdn.sockjs.org/sockjs-0.3.min.js'};
SockJS client, version 0.3.4

[domino14]

Hi, there was no load balancer involved, and most of the time the websocket will connect properly and my app will work. But we still get these 'null' connection objects pretty frequently (much more than Eugeny's sample above... this is a very simple chat app, just a few lines of code).

[tangor86]

We also do not have load balancer yet.

[kamalkishor1991]

+1
please look into this issue.

[brycekahle]

Looking at the code, it is not obvious how this could happen. I need help with reproduction steps in order to fix this bug.

[brycekahle]

Closing due to inactivity.

[domino14]

doesn't sound very inactive, i would assume the error was still happening but now i'm using Go and websockets or something

[brycekahle]

@domino14 Inactive in the sense that I asked for help reproducing almost 4 years ago and no one responded. If someone can provide a reproduction case, or even debug logs of this happening, it would be incredibly helpful.

Issues where the reporter and/or community are not actively working with me to get them fixed will be closed. I prefer to work with folks willing to put in some effort to get their issues fixed. This library and my time is provided for free. You cannot just file an issue, disappear, and expect it to get fixed.

[Discordius]

This appears to currently be happening with Meteor in production settings. I sadly don't have a reproduction, but it now seems somewhat more urgent, and a reproduction is more in reach. See this issue: meteor/meteor#10468

[luddd3]

I have also experienced it in production. It manifested for us when we went from node version 10.15.0 to 12.15.0. Sadly I don't know how to reproduce it. I'll use a work-around similar to what Meteor is doing.

[tsteuwer-accesso]

While I realize this bug is closed, I do want to let you know this issue does happen to us. We are unable to replicate as it happens completely randomly. We also notice it only happens when running on AWS EC2 servers using Node 12.16.2. It's likely doing it on other versions of Node, as noted in the above cases, however, we wanted to make that distinction. We have several other servers on REHL 6 where this issue doesn't happen. For now we're just going to use the below code:

server.on('connection', (conn) => {
   if (!conn) return;
   ....
});