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.
After some consideration, we decided that the extra package list in the README
is not up to date, will never be kept up to date and as such, is actively
unhelpful.
Move the list of packages out of the top section of the `meteor-platform` README.md,
because it doesn't play well with `meteor show`. Leave it in the section below for
people that run into the README in some other context (for example, Atmosphere).
This unit test demonstrates 20-second solving time. Thanks to the
CatalogCache abstraction, the data provided to the solver in the test
is exactly the data it gets when running the “meteor” command in a test
app with a bunch of packages in .meteor/packages and no .meteor/versions
file.
The test is hidden behind an environment variable:
CONSTRAINT_SOLVER_SLOW_TESTS
Previously, “meteor update foo” meant “ignore .meteor/versions for foo”,
which would upgrade if “foo” was a root dependency, and downgrade if foo
was only a transitive dependency.
Now, we make sure to try to upgrade foo even if it is not a root
dependency.
See #3282.
For pages using a ROOT_URL="" setting with a path component (eg.
"myproject.com/beta"), the CSS autoupdate would break the page, because
it would set the autoupdate CSS files' URL to /<longidstring>.css, while it
should have been /beta/<longidstring>.css. Added the required
ROOT_URL_PATH_PREFIX.
CS.Input is a serializable representation of the “problem.” It includes
the arguments to PackagesResolver#resolve, and also the catalog data
loaded into the CatalogCache. It’s independent of the solver, and
doesn’t even know about PackagesResolver or Resolver.
Along the way, get rid of the _testing and _debug flags. “_testing”
came about to avoid running the real cost function on some of the unit
tests, but it doesn’t actually seem to matter anymore for correctness
or performance of the tests. “_debug” was just used to enable some
console.logs, and possibly shouldn’t have been committed in the first
place.
Don’t mutate the “options” object in PackageResolver#resolve, and don’t
pass it on to _getResolverOptions.
At this point, this is rearranging deck chairs on the Titanic, but
making this code more understandable helps me replace it.
PackageResolver no longer loads data from the Catalog. Instead, it
tells CatalogLoader what to load, and it sets up the Resolver based
on what it finds in the CatalogCache.
PackageResolver now creates the Resolver inside resolve(…). If the tool
were to invoke resolve(…) multiple times on the same PackageResolver
(which it doesn’t at the moment), the CatalogCache would persist, but
not the Resolver. (Note that PackageResolver#resolve makes multiple
calls to the same Resolver#resolve internally.)
The purpose of this change is to stop using Resolver to store the
dependency graph. Resolver will be replaced with a logic-solver-based
implementation that will not represent the graph as is, but instead
encode the graph as a satisfiability problem. Meanwhile, CatalogCache
is better at storing the graph than Resolver was, because it is easy
to populate, query, and serialize.
This change brings us back to a functional “devel”.
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).
This is a breaking change to package-version-parser.
A PackageConstraint used to look like this:
```
{ name: String,
constraintString: String,
constraints: [{version: String|null,
type: String}]}
```
Now it looks like this:
```
{ name: String,
constraintString: String,
vConstraint: {
raw: String,
alternatives: [{versionString: String|null,
type: String}]}}
```
Where (vConstraint instanceof VersionConstraint) and
(vConstraint.raw === constraintString).
This achieves several desirable changes at once.
* `constraint.constraints` for the disjuncts in “1.0.0||2.0.0”
was confusing. `alternatives` is better.
* Having a class for VersionConstraint will come in handy because
we can add methods to it, and we can use it in the constraint
solver to represent the problem statement.
* The names “vConstraint” and “versionString” are a little verbose,
but there really shouldn’t be a lot of code that dives into this
structure, and I really wanted to avoid anyone ever writing:
`constraint.constraint.alternatives[0].version`, and then wondering
what sort of object that was (not a parsed PackageVersion! we could
parse eagerly but that might be slow).
Mostly I just made parseConstraint clearer and gave the return value a
prototype.
There are new unit tests, and the existing ones have been given much
better names.
PV.parseConstraint also now optionally takes two arguments, a package name and a version constraint. We can eventually propagate this feature to the tool and stop concatenating with “@” so much.
I’m referring to “foo@=1.0.0” as a PackageConstraint and “=1.0.0” as a version constraint. I’ll probably add a VersionConstraint class too.
