In Session.close, `self.socket.close` could trigger this event handler:
socket.on('close', function () {
if (socket._meteorSession) {
Fiber(function () {
socket._meteorSession.close();
}).run();
}
});
which could trigger a reentrant call to Session.close. The self.inQueue
guard was not sufficient to stop multiple execution, because it was too
low.
Symptoms included:
- The "sessions" server fact would be decremented twice and become
inaccurate (and even negative!)
- Connection.onClose callbacks could be called twice
Fixes#3331.
This reverts commit 67bea9c102.
See https://github.com/faye/permessage-deflate-node/issues/1
This can be consistently replicated by running test-packages ddp (note
that the tests pass but then the server crashes). "livedata server -
connection in publish function" specifically is enough
By default, we attempt to use this for every websocket message on both
client and server.
On the server, we provide the SERVER_WEBSOCKET_COMPRESSION environment
variable to control compression. If $SERVER_WEBSOCKET_COMPRESSION is
set, then it must be valid JSON. If it represents a falsey value, then
we do not use permessage-deflate at all; otherwise, the JSON value is
used as an argument to deflate's configure method; see
https://github.com/faye/permessage-deflate-node/blob/master/README.md
We do not provide a way to use it only on some messages. The underlying
spec allows this but permessage-deflate does not; see
https://github.com/faye/permessage-deflate-node/issues/2
We do not provide a mechanism to control compression parameters on the
client side. The assumption is that the common reason to care about
compression parameters is to control server per-connection memory
usage. (The noContextTakeover configuration parameter should save some
memory and still allow for some compression, for example.)
Addresses #3007 (which will not be fixed until this change is deployed
on the package server as well).
These errors should look like connection errors, not clean closes:
- Heartbeat timeout (DDP-level or SockJS-level)
- Connection timeout (SockJS implementation)
The "disconnected with no error while waiting for something we asked
for" error in ServiceConnection is now a DDP.ConnectionError so that it
prints better.
If a command refuses to run due to a catalog sync error, it should print
the error. (Commands that merely warn that they could not sync don't
print that error, unless METEOR_LOG=debug.)
These errors should look like connection errors, not clean closes:
- Heartbeat timeout (DDP-level or SockJS-level)
- Connection timeout (SockJS implementation)
The "disconnected with no error while waiting for something we asked
for" error in ServiceConnection is now a DDP.ConnectionError so that it
prints better.
If a command refuses to run due to a catalog sync error, it should print
the error. (Commands that merely warn that they could not sync don't
print that error, unless METEOR_LOG=debug.)
This should mean that you can access the package server from behind a
corporate firewall.
I tested this by setting up a Linux machine that doesn't have access to
packages.meteor.com:
$ sudo iptables -A OUTPUT -d 54.225.216.115 -j DROP
$ sudo iptables -A OUTPUT -d 184.72.252.20 -j DROP
$ sudo iptables -A OUTPUT -d 23.23.114.56 -j DROP
I confirmed that these commands both fail:
$ curl https://packages.meteor.com/
$ ./meteor search asdf # when it needs to sync first
I bought a proxy server from Proxy Bonanza and confirmed that setting
the environment variable HTTPS_PROXY to
https://PROXYUSERNAME:PROXYPASSWORD@PROXYIP:PROXYPORT/
made both of the commands above succeed.
Fixes#2515.
We want to support running DDP through a corporate proxy, but the
higher-level faye-websocket can't support that and won't be changed to
allow that: https://github.com/faye/faye-websocket-node/pull/30
Fair enough. Let's just switch to the lower-level module, since we don't
care about getting a browser-compatible websocket API.
This is a first step towards fixing #2515.
