/meteor

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make METEOR_WATCH_PRIORITIZE_CHANGED opt-out instead of opt-in. #8866

Merged
merged 1 commit into from Jul 10, 2017

Conversation

Reviewers

@abernix abernix

Assignees

@benjamn benjamn

Labels
None yet
Projects
None yet
Milestone
  Release 1.5.1
4 participants
@benjamn @davidecantini @klaussner @abernix
@benjamn
Member

benjamn commented Jun 30, 2017

This restores the behavior of 8c70716 by default, with the option of disabling the prioritized file watching system by setting METEOR_WATCH_PRIORITIZE_CHANGED explicitly to "false".

The self-tests where the environment variable is explicitly set form a nice to-do list of tests that should be improved to be more robust to cope with differences in file watcher timing.

Helps with #8648 and similar issues.
@benjamn
Make METEOR_WATCH_PRIORITIZE_CHANGED opt-out instead of opt-in. 
This restores the behavior of 8c70716 by
default, with the option of disabling the prioritized file watching system
by setting METEOR_WATCH_PRIORITIZE_CHANGED explicitly to "false".

The self-tests where the environment variable is explicitly set form a
nice to-do list of tests that should be improved to be more robust to cope
with differences in file watcher timing.

Helps with #8648 and similar issues.
Verified
This commit was signed with a verified signature.
@benjamn benjamn Ben Newman
GPG key ID: 15D2E57778C1A4BF Learn about signing commits
Loading status checks…
c5cd220

@benjamn benjamn added this to the Release 1.5.2 milestone Jun 30, 2017

@benjamn benjamn self-assigned this Jun 30, 2017

@abernix

abernix approved these changes Jul 4, 2017
View changes

LGTM! (The run - run test failure passed on re-run)

@benjamn benjamn modified the milestones: Release 1.5.1, Release 1.5.2 Jul 10, 2017

@benjamn benjamn merged commit 86eedd4 into release-1.5.1 Jul 10, 2017
4 checks passed

4 checks passed

CLA Author has signed the Meteor CLA.
Details
ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@abernix abernix referenced this pull request Jul 17, 2017

Closed

Large number of node_modules/files causes "too many open files" on OS X #6952

@davidecantini

This comment has been minimized.

Sign in to view

davidecantini commented Jul 29, 2017

After upgrading to 1.5.1, I started to experience cases like modifications to files not being immediately effective, just like if the previous (cached) version of the modified files are (wrongly) used. That makes the (local) development cumbersome. The good thing is that after setting METEOR_WATCH_PRIORITIZE_CHANGED=false, things appeared to work properly like they've always been until version 1.5. This is just a heads up that the prioritized file watching system may have some problems and not be ready (if so, METEOR_WATCH_PRIORITIZE_CHANGED=false, should be the default, until it's more stable)
@klaussner

This comment has been minimized.

Sign in to view
Collaborator

klaussner commented Jul 29, 2017

@davidecantini That sounds like this issue, which will be fixed in Meteor 1.5.2. 🙂

benjamn added a commit that referenced this pull request Aug 11, 2017

@benjamn
Immediately dirty optimistic functions when relevant paths modified. 
Should fix #8988 and #8942.

Now that #8866 is the default behavior, it can take up to 5000ms for
changes to files modified during the build process to be noticed.

Before #8866, when we called e.g. files.writeFile(path), a native file
watcher would notice the change immediately, almost always before the
build process read the file again. This was definitely racy, but we were
getting away with it consistently... until #8866.

I was able to reproduce the problem in #8988 by running

  echo some-local-package-name >> .meteor/packages

in an app with a local package of the given name. After debugging the
endless rebuild cycle, I found that .meteor/versions was being rewritten
by files.writeFile during the build process, but the file watching system
was not noticing the change in time to prevent watch.isUpToDate from
returning true. The change was finally detected when restarting the
Watcher responsible for .meteor/versions, which of course triggered
another rebuild, so the same problem kept happening again and again.
Verified
This commit was signed with a verified signature.
@benjamn benjamn Ben Newman
GPG key ID: 15D2E57778C1A4BF Learn about signing commits
Loading status checks…
88c39a5

@benjamn benjamn referenced this pull request Aug 11, 2017

Merged

Immediately dirty optimistic functions when relevant paths modified. #9007

benjamn added a commit that referenced this pull request Aug 11, 2017

@benjamn
Stop setting METEOR_WATCH_PRIORITIZE_CHANGED=false in self-tests. 
Assuming #9007 fixes the file watcher timing problems, it should no longer
be necessary to disable the optimizations of #8866.
Verified
This commit was signed with a verified signature.
@benjamn benjamn Ben Newman
GPG key ID: 15D2E57778C1A4BF Learn about signing commits
Loading status checks…
c68810a

benjamn added a commit that referenced this pull request Aug 11, 2017

@benjamn
Immediately dirty optimistic functions when relevant paths modified. 
Should fix #8988 and #8942.

Now that #8866 is the default behavior, it can take up to 5000ms for
changes to files modified during the build process to be noticed.

Before #8866, when we called e.g. files.writeFile(path), a native file
watcher would notice the change immediately, almost always before the
build process read the file again. This was definitely racy, but we were
getting away with it consistently... until #8866.

I was able to reproduce the problem in #8988 by running

  echo some-local-package-name >> .meteor/packages

in an app with a local package of the given name. After debugging the
endless rebuild cycle, I found that .meteor/versions was being rewritten
by files.writeFile during the build process, but the file watching system
was not noticing the change in time to prevent watch.isUpToDate from
returning true. The change was finally detected when restarting the
Watcher responsible for .meteor/versions, which of course triggered
another rebuild, so the same problem kept happening again and again.
Verified
This commit was signed with a verified signature.
@benjamn benjamn Ben Newman
GPG key ID: 15D2E57778C1A4BF Learn about signing commits
0f9c58d

benjamn added a commit that referenced this pull request Aug 11, 2017

@benjamn
Stop setting METEOR_WATCH_PRIORITIZE_CHANGED=false in self-tests. 
Assuming #9007 fixes the file watcher timing problems, it should no longer
be necessary to disable the optimizations of #8866.
Verified
This commit was signed with a verified signature.
@benjamn benjamn Ben Newman
GPG key ID: 15D2E57778C1A4BF Learn about signing commits
fb344ab

benjamn added a commit that referenced this pull request Aug 11, 2017

@benjamn
Stop setting METEOR_WATCH_PRIORITIZE_CHANGED=false in self-tests. 
Assuming #9007 fixes the file watcher timing problems, it should no longer
be necessary to disable the optimizations of #8866.
Verified
This commit was signed with a verified signature.
@benjamn benjamn Ben Newman
GPG key ID: 15D2E57778C1A4BF Learn about signing commits
fa4a68e

benjamn added a commit that referenced this pull request Aug 11, 2017

@benjamn
Stop setting METEOR_WATCH_PRIORITIZE_CHANGED=false in self-tests. 
Assuming #9007 fixes the file watcher timing problems, it should no longer
be necessary to disable the optimizations of #8866.
Verified
This commit was signed with a verified signature.
@benjamn benjamn Ben Newman
GPG key ID: 15D2E57778C1A4BF Learn about signing commits
56aea02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment