Very exciting to see significant development around the performance of Meteor to address scalability concerns that after all these years continue to plague the framework.
Performance gains for methods, which I’m sure are utilized more for commercial / production applications than reactivity/subscriptions, will be well received in the community.
Thanks for response we did reset local database as well.
So far have had a great experience with 3.1.1 in production.
I have noticed a lower amount of memory, but a lot more context switches!
What does it mean? Is that bad?
Thanks for testing, it’s great to see memory usage reduced.
Regarding context switching or interrupts, this seems to be a result of parallelism, right? Since the core code now processes batches in the async queue, it might lead to more of that. I’m not too familiar with this metric. But as a positive outcome, it will also reduce processing time.
I’ll reach out to you privately to test a few things and hopefully gain more insights into it.
We just released a video where I chat with @nachocodoner and @grubba about what we’ve done in this release: https://www.youtube.com/watch?v=tZY6jZGU9Ok
I was about to start missing @leonardoventurini updates. Great job on those video, please keep them coming 
The production value of these videos is excellent. Really grateful the investment and effort has been put into this. Goes a very long way. Major congratulations on being able to pull these update videos off.
Thanks for the great job !
One question I have not been able to answer by looking through forums or git…
==> Which exact release of mongodb is bundled with Meteor 3.1.1 (+ where may I find the answer for next release) ?
Best regards
Meteor 3.1.1 is bundled with MongoDB 7.0.5
You can find the versions in: /scripts/build-dev-bundle-common.sh
Thanks for your great work on Meteor! I’m just about to test my whole app manually after my Meteor 3 upgrade, so I decided to use the new 3.1.1 for this.
When I start the server, it shows a lot of warnings like these:
I’m a bit confused, because I thought updateAsync is now the way to go? Or is Collection2 using some low-level Mongo DB APIs here? Is there a fix for this already available?
[Update: There’s already an issue for this here: Triggers deprecation warnings in Meteor 3.1.1 allow-deny package · Issue #462 · Meteor-Community-Packages/meteor-collection2 · GitHub]
Also seeing this:
Yet I don’t know where exactly this is coming from?
For the util._extend warning that is coming from a dependency. There is a fix for this already merged in 3.1.2.
As for the updateAsync issue I have a PR on that in collection2, but the tests are failing and I’m waiting for feedback to better understand if my fix makes sense.
Thanks for the fast response! I skipped Meteor 3.1.1 for now, since I am also awaiting feedback on the roles changes.
Based on your stack trace, the issue happens from the collection2 library, which uses an outdated method for configuring allow/deny rules. The problem isn’t with updateAsync as a Mongo operation or any other, but rather with how these allow/deny rules are set up to let client operations affect the server directly.
Previously, both update and updateAsync could be used within collection.allow({ <here> }). This duplication added no value, as allow/deny rules only need a single validator for client operations, regardless of whether the operations are async or sync.
In 3.1.1 onwards, allow/deny validators are configured solely through insert, update, and remove options, which can include async validation logic. We’ve also made additional fixes in our revision of this feature, as happened on this PR: Tweaks on allow/deny rules by nachocodoner · Pull Request #13499 · meteor/meteor · GitHub
Community packages, like collection2, must stay updated with the latest standards. You can use METEOR_NO_DEPRECATION to ignore warnings, even with a regex to target only allow/deny ones. However, it’s good when seeing them to report these issues or fixes for these packages to address deprecations and prepare for breaking changes in future Meteor minor versions.
Regarding this we have been discussing it on a github issue here, GitHub · Where software is built
We will probably asses to solve this by forking a library used internally that uses deprected way to extend objects.
Thanks for these explanations!
@grubba I think 3.1.1 is not yet the recommended version. Is that right?
I still get “Not updating the release, because this app is at a newer release (METEOR@3.1.1) than the latest recommended release (METEOR@3.0.4)”
Ok, I read the updates as they come but I guess this is the first time I understand how you promote the recommended versions :).
