Closed rluba closed 8 years ago
Can you do something like this rather than the setTimeout
?
https://github.com/hapijs/good/blob/v7.0.0/lib/monitor.js#L199-L202
Also, have you run npm test
locally before submitting a PR? Your code is not passing lint.
Also, I'm not 100% certain I want to make this change as it potentially has downstream impacts and I'm not really doing anything other than critical bug fixes for the 6.x.x line at present.
Interesting that c244d6d broke on the node4 / hapi 10 build. Might be a lovely race due to the setTimeout
s (it passed for d3c5f20).
If all you're trying to do is get your tests to stop yelling at you about the potential EventEmitter leak, you can run (just in your test code mind you)
process.stdout.setMaxListeners(0)
// OR
process.stdout.setMaxListeners(Infinity)
@arb Sure, but that just feels like an ugly workaround for the problem, not a real solution.
I’ve replaced the flaky setTimeout
in the monitor test with a separate test that uses a latch for synchronization to avoid the race condition between the setTimeout
in the implementation and the one in the test (without adding an artificial delay to the test).
@rluba as I said before, I don't think I can merge this in safely at this point. I will admit that I 100% made a mistake in this version of good by NOT pushing null
into the data stream and instead using the goofy "stop" event from good to tell streams to tear themselves down.
That being said, I can't say with any certainty what this would do to all of the good-reporters that might not be expecting null
and are already in existence in the wild.
If the EventEmitter leak is what's causing you problems, try my suggested fix. I encourage you to follow along with the v7.0.0 branch of good. Maybe we can catch issues like this before it's released :smile:
That being said, I can't say with any certainty what this would do to all of the good-reporters that might not be expecting null and are already in existence in the wild.
@arb The reporters will never see a null
data event! Pushing a null
simply sets the EOF
flag and listeners will receive an end
event after reading all data. If they don’t handle it, they will work as before (but without leaking resources anymore).
@arb Would you merge this into the 7.0
-Branch?
I've already implemented this in the 7.0 branch, but there is plenty of other things to do in there.
https://github.com/hapijs/good/commit/dba94981ff0895b58320ae39f008e7c46ff2581a
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.
I discovered this by accident in my tests: When creating and stopping hapi servers (for each test) with attached
good
plugin and usinggood-console
as reporter, you’ll pretty soon see something like this:… because
good-console
pipes the monitor’s_dataStream
(after some tranformation) intoconsole.stdout
, thereby attaching several event listeners to the latter. But the_dataStream
is never closed, so the streams and event listeners remain attached to the global object.I see two possible solutions:
good-console
tostdout
,stop
event andgood
toEOF
the_dataStream
so that all piped-to streams are disconnected automatically.This PR implements 2.
I’m not a big fan of the
setTimeout
workaround, but closing_dataStream
right away causes problems when usingextensions: [stop]
: Its event handler also listens to the server’sstop
event, receives it after the monitor and then tries to push into the closed_dataStream
, causing an exception. (The monitor deregisters the extension event listeners, but the currentstop
event is already being processed.)Instead of the
setTimeout
one could use a guard clause in the extension event listener but then thestop
event would be dropped.