I am using the withTracker() HOC to setup my subs in React.
In order to track down a performance problem, I analyzed the DDP traffic sent from the browser and back - and noticed that each time I change the input params, Meteor first sends an unsub message, followed by a sub message with the new parameters.
In effect, the previous documents are removed and then re-added again, even if the new query comprises all of them. In my use-case it’s a geospatial query that drops map data even if I zoom out and thus set a wider viewport.
This only happens if I zoom out. If I zoom in, only documents are removed, which is what I’d expect. However, Meteor still unsubs and subs right afterwards. And sometimes, even zooming out works as expected, i.e. only documents are being added.
Why is this so? I always thought that re-subs would only update the deltas (changed, added, removed data)?
Is it the expected behavior to unsub a sub before you send a new sub? I read through the DDP docs, but couldn’t find any information on how that handshake actually works.
Thanks, this basically matches my understanding after looking at the subscription code in the ddp-client package, so the unsubs seem to be intentional.
But this still doesn’t explain why data that has been part of the initial sub gets removed before it is being re-added again (even if the parameter set comprises the old documents as well).
So, you mean that in case the parameters change, all documents would be re-transmitted again? If this is so, then why does a zoom into the map behave differently (only documents are dropped)?
And why are the documents being added after being removed, if the unsub is being sent after the sub?
In this list, you can see that the documents are being re-added once the server has sent the “nosub” message (this was a zoom-in operation, i.e. only documents should be removed because they get out of the viewport):
I have been chasing this for days now. Turns out that the effect was caused by adding this.unblock() to the publication, as recommended in this thread:
I was totally unaware of the fact that this causes the publication to send all data on re-subscriptions instead of just the deltas. Seems as if adding this.unblock() to all pubs is not the best idea.