Scheduling of next ticks from within the next tick handler will result
in a tight execution loop where a timer cannot break into.
This test was invalid
We were being very aggressive in our connection creations, resulting
in the pipeline flood detection to drop us. Relax how fast we're
creating these connections so the gc can run all its tests.
It wasn't doing anything, and actually due to
3ae0b17c76, it was causing
the readline `prompt()` function to be overwritten
which throws an error in the REPL shortly after.
Expose localPort for binding to a specific port for outbound
connections.
If localAddress is not specified '0.0.0.0' is used for ip4 and '::'
for ip6 connections.
Fixes#7092
The reason this wasn't working was because after restart, when restoring
breakpoints the scripts wasn't loaded, so the breakpoint.script was
undefined. As a fix I added another check to use breakpoint.scriptReq
instead of breakpoint.script, which is the same except when the
breakpoint is a function.
fixes#7027
In some scenarios this will strip the DOF sections for DTrace, and in a
future world where we re-export all static libraries it would defeat
that purpose.
If an input stream would emit `end` event, like
`fs.createReadStream`, then readline need to get the last line
correctly even though that line isnt ended with `\n`.
Given the assert message, and the fact that endCb is always true
in the assert, I am pretty sure the test author was intending
to test for finishEvent, not endCb.
In this test, an HTTP server was ending the response before
consuming all the data sent in the PUT request.
Ending the response would cause the socket to be destroyed,
and since there is some data still to be read, an ECONNRESET is
surfaced on the client side, event though the client has already
ended its side and even seen a 'finish' event.
See:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2
While it is certainly admissible for the server to send a response
before consuming the entire request, it seems reasonable to
expect that the server would close the connection afterwards
and that the ECONNRESET would be raised on the client.
So I have changed the test to wait until the entire request has been
consumed before sending the response.
Before sending a socket from a cluster master to a worker,
we would call listen in UV but not handle the error.
I made createServerHandle call listen on Windows so we get a chance
the handle any bind/listen errors early.
This fix is 100% windows specific.
It fixes test-cluster-bind-twice and
test-cluster-shared-handle-bind-error on Windows.