[Solved] Trying to understand why DDP unsubs on re-sub

help
1

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.

2

Here is what’s in the documentation

3

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).

4

Here you can see a sample of such a document being removed and re-added afterwards:

image

This is the reaction on this sub-unsub message sequence:

image

5

My understanding is that merging only happens when both subs exist.

Since in this case, no multiple subs exist, no merging is happening

6

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?

7

Seems you changed your post above.

Not sure why it was happening. And why sometimes only

8

Yeah, I noticed afterwards that sometimes it works as expected, sometimes not. Wanted to make this clear.

9

Update: I now also had cases where documents were added even if I zoomed in (and thus limited the visibility of the documents).

10

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):

image
image651×856 141 KB

So, the sequence in these cases is:

  • sub to the new parameters
  • unsub from the old ones
  • remove all documents
  • send the nosub message
  • re-send documents

And here’s another sample where only documents are being removed (still a map zoom in):

image

In these cases, the server sends the nosub after all deletions, and no documents are being added again.

So, the sequence in these cases is:

  • sub to the new parameters
  • unsub from the old ones
  • remove all documents
  • send the nosub message

If I zoom even further in, I see this:

image

Here, all documents are being removed before being re-added immediately afterwards.

And after another (very slight) zoom in, I get this:

image

No changes to the document set here (which is what I would actually expect).

This definitely looks as if some kind of merging is happening, but in an inconsistent manner.

2 Likes
11

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.

3 Likes