Subscriptions rerun each 10 seconds

[peerlibrary]

Subscriptions rerun each 10 seconds

[mitar]

I think a new issue would be better instead of commenting on and old one.

But this is a great catch! No, this was not expected. I have copied this from the client side code, which does not have this restriction. Maybe open an issue in reactive-mongo package and we can work through it there?

[mitar]

This sounds like something connected with polling instead of oplog? Polling is every 10 seconds? Do you have oplog enabled on production?

Can you share some code?

Also, rerunning on userId change is something done already. Do you need to use autorun?

[dpatte]

I suspected polling but i have been told that my deployed system is actually using oplog.

Changing userId changes the list of users whose data I want to publish. I actually then publish more detailed data about each user, as well as their docs.

[mitar]

Can you show some code?

[dpatte]

It turns out that the deployed system is using polling after all. So, yes it has to do with polling.
I have also discovered that it also only occurs on pages that have Router.onBeforeAction(requireLoginRt, .....
I'm now beginning to think it is a router issue, or a conflict between iron router and reactive publish, or related to polling's lazy comparison of record changes.

[mitar]

Can you create a small reproduction?

[dpatte]

Actually, I removed the autorun, and I still have the issue. I guess the problem is somewhere else. Thanks for putting up with my questions.

[etyp]

@mitar I'm a bit confused here - it seems like any find done within an autorun (excluding the cursor which is returned) uses the polling observe driver.

For example, if I have:

Meteor.publish('messagesForGroup', function (groupId) {
  this.autorun(() => {
    const group = Groups.findOne(groupId, { fields: { members: 1 } });
    if (group.members.indexOf(this.userId) > -1) {
      return Messages.find({ group: group._id });
    }
  });
});

It seems like the findOne Groups.findOne(groupId, { fields: { members: 1 } }); uses polling instead of oplog.

Is that expected?

[etyp]

From what I can tell, the reactive-mongo package adds addedBefore and movedBefore callbacks to fetch, map and forEach on cursors.

Because of this, it fails the first check in observeChanges in Meteor's mongo_driver.js for whether or not it can use oplog.

The presence of addedBefore and movedBefore means that ordered returns true when the driver calls LocalCollection._observeChangesCallbacksAreOrdered.

Was it ever intended for finds inside of server-side autoruns to use oplog or are they always expected to fall back on polling?