Instead, increase polling interval for that file/dir to 500ms from 5s.
Fixes#3336.
The most common case where this was occuring is when you're on Linux and
your inotify max_user_watches is too low. A wiki page will explain how
to increase this. In debug mode, a message will tell you to go to the
wiki page if you hit the limit (we may later expose this message by
default, but it is part of the new user experience).
Conflicts:
meteor
tools/safe-pathwatcher.js
This strategy was suggested by @glasser after we realized just how
hopeless it is to probe the file system to test pathwatcher:
https://github.com/meteor/meteor/issues/3285#issuecomment-67296961
I've made some attempt to de-duplicate these events (since we're
effectively watching twice now), but we have other mechanisms for dealing
with bursty file change events, so these measures do not need to be
completely bulletproof.
Fixes#3284 (again).
This also un-breaks soft refresh for troposphere packages:
previousIsopack was accidentally being set to an
{isopack,pluginProviderPackageMap} object, and so the "can we reuse the
previous one" check was never actually passing.
Running the two versions of the test in parallel is safe because they run
in separate processes, and a good idea because it cuts the time taken by
the test in half, from 36sec to 19sec.
Conflicts from devel:
tools/tests/old.js
Previously we were testing pathwatcher.watch by creating a file in
.meteor/local, but developers using Vagrant VMs often mount .meteor on a
different (non-network) file system, for Mongo's sake.
Writing the file directly in the app directory increases the likelihood
that it will interact with pathwatcher in the same way as other source
files the developer will be editing.
Conflicts from devel:
tools/safe-pathwatcher.js
Typically, there is a delta due to adding the test slice of the
published package, but there's no reason to tell the user about this or
save it in .meteor/versions.
Specifically, we only compile them if there's a cordova platform in the
current project, or if we are publishing the package.
(Ideally, we wouldn't require every published package to have
web.browser and web.cordova unibuilds --- we'd just publish a 'web'
unibuild unless there's actually a difference between the two. But we
are not there yet.)
This adds an extra flag to isopack-buildinfo.json, so that we know to
rebuild all the isopacks when we add the first cordova platform (or
remove the last cordova platform).
The implementation around publish is a little clunky; if you're in a
non-Cordova app and run meteor publish, it will rebuild all the packages
with web.cordova, and the next time you prepare the app it will rebuild
them again without it. It does work though.
Fixes#3274.
Previously, we would register the circular dependency error properly
with buildmessage, but then try to build the package with a circular
dependency anyway, leading to a crash.
Fixes#3280.
This will refresh the status bar more often and make the build tool more
responsive to signals.
Now that yield uses setImmediate, this has minimal effect on
performance.
- Lower STATUS_INTERVAL_MS from 500 to 50. Note that we were effectively
doing 150 or 100 anyway: the _pollFiber was polling every 100, and the
nudged _throttledStatusPoll was actually throttling at the default of
150, not 500, because the Throttled constructor was being invoked
incorrectly (without the named 'interval' option).
- Use the same throttler for _pollFiber and nudge.
Fixes#2846. Fixes#2847. Fixes#2979.
Errors in the build process that could be fixed by refreshing the
catalog now cause the catalog to refresh, assuming we have not already
refreshed it recently and that we are not offline.
These commands now don't need to refresh at startup: remove, run, debug,
create, build, bundle, deploy, test-packages, rebuild, and self-test
It should be OK for create to throw SpringboardToLatestRelease even
without refreshing, since release.latestKnown is still something we know
about.
AppRunner.stop needs to be able to cause any Future which the AppRunner
is waiting on to return, so that it can get back to the top level of its
loop and return. (This is because for some reason it is important that
AppRunner.stop does not return until the app is guaranteed to be
stopped.) This had not been the place for the injected "wait for mongo
to start up before running the AppProcess" future.
This also means we can't use f.future() any more, because that code
assumes that it is the only code allowed to resolve its future (it
unconditionally resolves the future when the wrapped function returns,
which is an error if it is already resolved).
This is tested by 'run errors' which was failing. Also, the test should
only expect 2 unexpected exit code messages, not 3, since we don't print
the message the first time which didn't have a kill before it.
No need to introduce the LayeredCatalog anywhere it's not needed.
Simplify some more things about LayeredCatalog:
- remove unused containingCatalog link from localCatalog to
layeredCatalog
- because of that, simplify LayeredCatalog initialization to occur after
localCatalog (no more circular references required)
- drop some other dead LayeredCatalog methods
