Prior to v0.10, Node ignored ECONNRESET errors in many situations.
There *are* valid cases in which ECONNRESET should be ignored as a
normal part of the TCP dance, but in many others, it's a very relevant
signal that must be heeded with care.
Exacerbating this problem, if the OutgoingMessage does not have a
req.connection._handle, it assumes that it is in the process of
connecting, and thus buffers writes up in an array.
The problem happens when you reuse a socket between two requests, and it
is destroyed abruptly in between them. The writes will be buffered,
because the socket has no handle, but it's not ever going to GET a
handle, because it's not connecting, it's destroyed.
The proper fix is to treat ECONNRESET correctly. However, this is a
behavior/semantics change, and cannot land in a stable branch.
Fix#4775
Running repl.start without the prompt set produces this error:
repl.js:95
throw new Error('An options Object, or a prompt String are required');
^
Error: An options Object, or a prompt String are required
at new REPLServer (repl.js:95:11)
at Object.exports.start (repl.js:321:14)
at Object.<anonymous> (/Users/dan/Dropbox/Documents/dev/nextgen/repl_test.js:5:6)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
Inform V8 that the zlib context object is tied to a large off-heap buffer.
This makes the GC run more often (in theory) and improves the accuracy of
--trace_external_memory.
In zlibBuffer(), don't wait for the garbage collector to reclaim the zlib memory
but release it manually. Reduces memory consumption by a factor of 10 or more
with some workloads.
Test case:
function f() {
require('zlib').deflate('xxx', g);
}
function g() {
setTimeout(f, 5);
}
f();
Observe RSS memory usage with and without this commit. After 10,000 iterations,
RSS stabilizes at ~35 MB with this commit. Without, RSS is over 300 MB and keeps
growing.
Cause: whenever the JS object heap hits the high-water mark, the V8 GC sweeps
it clean, then tries to grow it in order to avoid more sweeps in the near
future. Rule of thumb: the bigger the JS heap, the lazier the GC can be.
A side effect of a bigger heap is that objects now live longer. This is harmless
in general but it affects zlib context objects because those are tied to large
buffers that live outside the JS heap, on the order of 16K per context object.
Ergo, don't wait for the GC to reclaim the memory - it may take a long time.
Fixes#4172.
Fix issue where SlowBuffers couldn't be passed as target to Buffer
copy().
Also included checks to see if Argument parameters are defined before
assigning their values. This offered ~3x's performance gain.
Backport of 16bbecc from master branch. Closes#4633.
This test starts two clustered HTTP servers on the same port.
It expects the first cluster to succeed and the second cluster
to fail with EADDRINUSE.
Reapplies commit cacd3ae, accidentally reverted in a2851b6.
Reject negative offsets in SlowBuffer::MakeFastBuffer(), it allows
the creation of buffers that point to arbitrary addresses.
Reported by Trevor Norris.
Make tools/install.py work with python 2.5
2.5 is still fairly widespread and does not include a json lib as
standard. Most python folk will have simplejson if they are in that
boat.
In general it seems a bit tricky to solve this perfectly...
Fix the following exception:
http.js:974
this._httpMessage.emit('close');
^
TypeError: Cannot call method 'emit' of null
at Socket.onServerResponseClose (http.js:974:21)
at Socket.EventEmitter.emit (events.js:124:20)
at net.js:421:10
at process._tickCallback (node.js:386:13)
at process._makeCallback (node.js:304:15)
Fixes#4586.
For example, to cross-compile from my OS X laptop for Raspberry Pi, you would
do something like:
$ make binary BINARYNAME=node-v`python tools/getnodeversion.py`-linux-arm-pi \
DESTCPU=arm CONFIG_FLAGS="--dest-os=linux"