(node) warning: possible EventEmitter memory leak detected

[Joan Roca]

Hi,
I've just downloaded the latest version from github (0.6.13) and I'm
seeing this warning:

22 Feb 11:22:53 - socket.io ready - accepting connections
22 Feb 11:24:24 - Initializing client with transport "xhr-polling"
22 Feb 11:24:24 - Client 20823611365631223 connected
(node) warning: possible EventEmitter memory leak detected. 11
listeners added. Use emitter.setMaxListeners() to increase limit.
Trace:
at Socket.<anonymous> (events.js:101:17)
at [object Object].<anonymous> (/home/joan/local/node/lib/
node/.npm/socket.io/0.6.13/package/lib/socket.io/client.js:83:20)
at [object Object]._onConnect (/home/joan/local/node/lib/node/.npm/
socket.io/0.6.13/package/lib/socket.io/transports/xhr-polling.js:
23:35)
at [object Object].check (/home/joan/local/node/lib/node/.npm/
socket.io/0.6.13/package/lib/socket.io/listener.js:77:12)
at Server.<anonymous> (/home/joan/local/node/lib/node/.npm/
socket.io/0.6.13/package/lib/socket.io/listener.js:33:14)
at Server.emit (events.js:45:17)
at HTTPParser.onIncoming (http.js:1078:12)
at HTTPParser.onHeadersComplete (http.js:87:31)
at Socket.ondata (http.js:977:22)
at Socket._onReadable (net.js:654:27)


Is this normal? Is it related to node?

[Truong Nguyen]

just got this, is this the same memory leak last week?

(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.

Trace: 

    at Socket.<anonymous> (events.js:101:17)

    at [object Object].<anonymous> (/Users/constantx/local/node/lib/node/.npm/socket.io/0.6.15/package/lib/socket.io/client.js:83:20)

    at [object Object]._onConnect (/Users/constantx/local/node/lib/node/.npm/socket.io/0.6.15/package/lib/socket.io/transports/xhr-polling.js:23:35)

    at [object Object].check (/Users/constantx/local/node/lib/node/.npm/socket.io/0.6.15/package/lib/socket.io/listener.js:77:12)

    at Server.<anonymous> (/Users/constantx/local/node/lib/node/.npm/socket.io/0.6.15/package/lib/socket.io/listener.js:33:14)

    at Server.emit (events.js:45:17)

    at HTTPParser.onIncoming (http.js:1078:12)

    at HTTPParser.onHeadersComplete (http.js:87:31)

    at Socket.ondata (http.js:977:22)

    at Socket._onReadable (net.js:654:27)

[Bjorn Tipling]

Getting this too.

warning: possible EventEmitter memory leak detected. 11 listeners
added. Use emitter.setMaxListeners() to increase limit.

On Feb 22, 3:34 am, Joan Roca <joanroca...@gmail.com> wrote:
> Hi,
> I've just downloaded the latest version from github (0.6.13)  and I'm
> seeing thiswarning:
>
> 22 Feb 11:22:53 - socket.io ready - accepting connections
> 22 Feb 11:24:24 - Initializing client with transport "xhr-polling"
> 22 Feb 11:24:24 - Client 20823611365631223 connected

> (node)warning: possible EventEmitter memory leak detected. 11
> listeners added. Useemitter.setMaxListeners() to increase limit.

[Ryan Gahl]

This is just an [annoying] opinion of node, where it's assuming you don't know what you're doing because you're using eventEmitters to wire up more listeners that its authors typically use in their apps :P

just do what the warning message says, use .setMaxListeners() for now to up how many listeners you can wire up before it complains, and perhaps petition for removal of this opinion from core if it annoys you enough.

+1 for removal of this opinion from core, btw

[Jason Webster]

Ryan, that's actually not the case at all. There is a leak in the
server side client library that will attach multiple event listeners
when using a polling transport. See pull request #161.
https://github.com/LearnBoost/Socket.IO-node/pull/161

On Mar 23, 10:07 am, Ryan Gahl <ryan.g...@gmail.com> wrote:
> This is just an [annoying] opinion of node, where it's assuming you don't
> know what you're doing because you're using eventEmitters to wire up more
> listeners that its authors typically use in their apps :P
>
> just do what the warning message says, use .setMaxListeners() for now to up
> how many listeners you can wire up before it complains, and perhaps petition
> for removal of this opinion from core if it annoys you enough.
>
> +1 for removal of this opinion from core, btw
>

[Guillermo Rauch]

The "leak" lasts only as long as the connection remains open, so it doesn't really translate in linear memory growth.

--
Guillermo Rauch
http://devthought.com

[Jason Webster]

Right, it will eventually recover. I did just want to note that it wasn't an annoyance of node, however. 

Sent from my iPhone

[Arnout Kazemier]

Sure it does recover, but having a user that has the XHR transport idle on your site for a couple of hours

shouldn't increase memory. So the message was right, there was a small innocent memory leak. But it's

not a "major" leak that needs patching right away.

Arnout Kazemier

in...@3rd-Eden.com

[Shripad K]

I dunno about the others but at times I have experienced stale connections (even after client disconnects) while using transports such as jsonp-polling/xhr-polling. No disconnection event is triggered for days together. I'm using socket.io on a realtime analytics app(still in testing. will go into production once such small issues are debugged.) Has anyone faced such problems? This is an edge case and I don't expect everybody to be recording disconnect events.. but in my app it is essential. :)

I obviously have tried hard to recreate such a scenario to report it. It should disconnect after the timeout. And since there are no subsequent requests from the browser the disconnection event should be triggered. Is there a good way to debug this? This happens quite a lot with jsonp-polling transport.

Any reason why jsonp-polling is used rather than CSSHttpRequest hack? http://nb.io/hacks/csshttprequest 

It is more stable and prevents executing arbitrary javascript on the client end. For some reason the messages are not buffered properly in jsonp-polling transport (with some messages being dropped) and the order is not preserved. In Safari it shows a throbber even after page load falsely indicating to the client that the page is still not loaded.