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.
This implements the user-facing APIs that lets one run a child process
and block until it exits.
Logic shared with the async counterpart of each function was refactored
to enable code reuse.
Docs and tests are included.
Don't use argument as callback if it's not a valid callback function.
Throw a valid exception instead explaining the issue.
Adds to #7070 ("DNS — Throw meaningful error(s)").
The number of connections achieved by the test can vary by platform
and by machine. Lowering the acceptance threshold so that the
test passes on Windows.
Don't use argument as callback if it's not a valid callback function.
Throw a valid exception instead explaining the issue. Adds to #7070
("DNS — Throw meaningful error(s)").
Make vm.runInContext() and vm.runInNewContext() stop copying the Proxy
object from the parent context into the new context when --harmony or
--harmony_proxies is in effect because it overwrites the new context's
native Proxy object.
This commit also adds a regression test for Harmony symbols. They work
okay in the current implementation and the test should ensure it stays
that way.
Conditional globals like 'gc' should only be recognized when --expose_gc
is set. The global.gc feature check works only when done eagerly, else
it lets through a leaked variable called 'gc'.
Before, `new String('foo')` would be inspected as `"{}"` which
is simply not very helpful. Now, a more meaningful
`"[String: 'foo']"` result will be returned from `util.inspect()`.
Boxed String, Boolean, and Number types are all supported.
Closes#7047
Try embedding the ` ... ^` lines inside the `SyntaxError` (or any other
native error) object before giving up and printing them to the stderr.
fix#6920fix#1310
The AsyncListener API has been moved into the "tracing" module in order
to keep the process object free from unnecessary clutter.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
Now the second field in asyncFlags will tell if the provider is
currently being watched, or listened for.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
These will be used to allow users to filter for which types of calls
they wish their callbacks to run.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
"flags" could mean one of many things, and multiple flag types could be
checked. So make the field more explicit on what type of flags are being
stored.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
Add a new 'tracing' module with a v8 property that lets the user
register listeners for gc events. The listeners are invoked after
every garbage collection cycle with 'before' and 'after' statistics.
Useful for monitoring tools that want to keep track of memory usage.
Create a new HandleScope before looking up the object context with
v8::Object::CreationContext(), else we leak the Local<Context> into
the current HandleScope.
That's relatively harmless unless the HandleScope is long-lived and
MakeCallback() is called a lot. In a scenario like that, we may end
up leaking a lot of memory.
What is unfortunate about this change is that we're trying hard to
eradicate the node_isolate global. Longer term, we will probably have
to change the MakeCallback() prototype to one that requires an explicit
v8::Isolate* argument.
Make it possible to invoke MakeCallback() on a v8::Value but only for
the variant that takes a v8::Function as the thing to call.
The const char* and v8::String variants still require a v8::Object
because the function to call is looked up as a property on the receiver,
but that only works when the receiver is an object, not a primitive.
If the call to writeBuffer completes asynchronously, we need to have
an oncomplete callback on the request object no matter what. The
writeQueueSize seems irrelvant to that regard.
Note that on Windows writeBuffer always completes asynchronously.
See related commit 9836a4eeda
Update the list of root certificates in src/node_root_certs.h with
tools/mk-ca-bundle.pl and update src/node_crypto.cc to make use of
the new format.
Fixes#6013.
Alexis Campailla
orangemocha@github.com
Timothy J Fontaine
isaacs
Christian
Bert Belder
Fedor Indutny
Kenan Sulayman
Brian White
Austin Moran
Ben Noordhuis
Nathan Rajlich
iamdoron
Trevor Norris
Benjamin Waters
Yuriy Nemtsov