Documentation about pollingIntervalMs and pollingThrottleMs is unclear

[ignl]

I am not sure if documentation is correct for Collection-find. In this blog post settings for Livedata optimization are called pollingInterval and pollingThrottle. Also I am not sure if default for pollingIntervalMs is really 10s? I tried various combinations but couldn't get it to work on meteor 1.4.0.1. Currently I try like this serverside:

messages.find({'metadata.thread': threadId}, {sort: {'date' : sort}, limit: limit, pollingThrottle: 12000, pollingInterval: 12000});

I expect a new message to be pushed to other client every 12s, but it seems meteor just updates them immediately anyway. Is this a correct way to do it?

[laosb]

This was not the interval of sending messages to client. It's about the interval of the server's polling database. Also keep in mind that if you modify data on server instead of DB, changes happened immediately, too.

[ignl]

Ok you closed it but is the documentation really correct? Is it really called pollingIntervalMs and pollingThrottleMs? If default for pollingInterval is 10s should it be set in ms or s (if I would like to poll db every every 20s should I set 20000 or 20)? And about pollingThrottle from documentation:

Minimum time to allow between re-polling. Increasing this will save CPU and mongo load at the expense of slower updates to users. Decreasing this is not recommended. In milliseconds. Defaults to 50 milliseconds.

This is exactly what I want. If it doesn't work like that then I would say documentation is really misleading which is exactly what I wrote in title.

[laosb]

slower updates to users there means slower direct DB update to users, not slower serverside updates to users, I think. The documentation is really unclear about this. Maybe add a link to the blog post you've mentioned? I'll reopen for other's thoughts.

Oh I just remembered, docs issues should go to meteor/docs. So closing this and I will post this to meteor/docs. Thank you for your reporting and please continue there.

[loredanacirstea]

@ignl

Docs are correct, with the exception of those 10sec (should be 10 ms).

1. Be sure that you are only updating MongoDB and not Minimongo - for example, if you update through Meteor methods, be sure you don't have client stubs.
2. Try this:

messages.find({'metadata.thread': threadId}, 
  {
    sort: {'date' : sort}, 
    limit: limit,
    disableOplog: true, 
    pollingThrottleMs: 12000, 
    pollingIntervalMs: 12000
  }
);

You have to disable oplog tailing. If you don't, you still get notified every time the MongoDB logs change.

I tested this with an observer on the client and it worked.

Cursor.observe({
    changed: (newdoc, olddoc) => {
      console.log('changed');
    }
})

[ignl]

OK that seems to be working, thanks! So the documentation problems would be:

1. In http://info.meteor.com/blog/tuning-meteor-mongo-livedata-for-scalability properties named without 'Ms'
2. Documentation must be very clear that disableOplog must be set to true if using pollingThrottleMs/pollingIntervalMs
3. 10s for pollingIntervalMs actually I think is correct, but still could be made more clear in docs. Here is the quote from a blog post:

The server will re-run the query every time another client on the same server does a write that could affect the results. It will also re-run periodically to pick up changes from other servers or external processes modifying the database. Thus poll-and-diff can deliver realtime results for clients connected to the same server, but it introduces noticeable lag (the default is 10 seconds, see below for more on this parameter) for external writes.

[abernix]

1. In http://info.meteor.com/blog/tuning-meteor-mongo-livedata-for-scalability properties named without 'Ms'

@ignl Thanks for pointing this out. @n1mmy Can the blog be updated to change pollingThrottle to pollingThrottleMs and pollingInterval to pollingIntervalMs (per this code and this code and the docs)?

2. Documentation must be very clear that disableOplog must be set to true if using pollingThrottleMs/pollingIntervalMs

I agree this could be more clear, but essentially when oplog isn't on (either because it's not available, or disabled), Meteor resorts to polling and these variables become relevant.

Would it be more clear if the docs added the text "When not using oplog, " as follows (In JSDoc format)?:

* @param {Number} options.pollingIntervalMs (Server only) When not using oplog, how often to poll this query when observing on the server. In milliseconds. Defaults to 10 seconds.
* @param {Number} options.pollingThrottleMs (Server only) When not using oplog, the minimum time to allow between re-polling. Increasing this will save CPU and mongo load at the expense of slower updates to users. Decreasing this is not recommended. In milliseconds. Defaults to 50 milliseconds.

3. 10s for pollingIntervalMs actually I think is correct, but still could be made more clear in docs. Here is the quote from a blog post:

Yes, 10s is the default for pollingIntervalMs (per this code). The docs literally say "Defaults to 10 seconds." – I don't see how this could be more clear.

[ignl]

Yeah for point 2 I would say "When not using oplog (when it's not available or disableOplog: true is used)" or something like that should be good. For point 3 maybe it's better to use the same metric - ms. So it could be 10000ms (10s).

[theadactyl]

@abernix @n1mmy changed blog post references. Can someone double-check it to make sure I've handled this correctly?

[abernix]

@theadactyl Perfect, thank you!

PR #7800 is open to solve the outstanding documentation issue and this issue will close automatically when it is merged.

Thanks, all.