socket.io redis store leaks channels

[brettkiefer]

Repro:

Socket.io 0.8.7
Run socket.io with the redis backing store.
run 'info' on your redis instance, noting the number of pubsub_channels
Create a websocket connection to socket.io
run 'info' again: you should now have 5 more pubsub_channels than before
Close the websocket connection
run 'info' again: you now have 3 more pubsub_channels than when you started

Repeat -- it leaks 3 channels each time.

Is this intended?

This line would cause it to leak 2 channels, because we're not unsubscribing in the non-local case https://github.com/LearnBoost/socket.io/blob/master/lib/manager.js#L516

But even if I remove the if (local) logic, I still leak one channel per opened and closed connection.

[3rd-Eden]

ping @dshaw ^

[dshaw]

On it.

[brettkiefer]

The third leaked subscription is this one: https://github.com/LearnBoost/socket.io/blob/master/lib/manager.js#L433

It looks like this is because the other processes never get a disconnect message, and it looks to me as though that's because connected process's manager never publishes a message on the 'disconnect' channel -- so that probably means we're leaking memory in the client processes as well as channels in the Redis instance. I'll issue a pull; if you want it against some repo other than this one, let me know which.

[dshaw]

@brettkeifer Pull Request #665 is not going to handle it correctly. Sorry, I've been tied up with Thanksgiving holidays. Landing patch(es) now.

[brettkiefer]

@dshaw Cool, and I see that you picked up the disconnect publish from c742735 in c110036 to get rid of the other leaked channel, so that looks like it ought to fix our issue, I'll give your changes a try. Thanks! I did it the way I did because it looked to me as though onClientDisconnect would only ever be called when 'local' should be true, so there was no need for the param -- can you explain if that reasoning was wrong?

@guille Uh oh, looks like this broke something for you, hence the reverts?

[rauchg]

It might or might not have broken our tests :D

[dshaw]

Tests run clean for me.

[dshaw]

@brettkiefer onClientDisconnect is called in 3 places, only one of which is with the local flag.

[dshaw]

Issue is with Travis, not dshaw. ;-P

[brettkiefer]

@dshaw Okay, got it - so a Socket.prototype.disconnect and a Manager.prototype.handleClient happen in processes where the client isn't 'local'?