Client keeps on sending subscribe requests (100/min)

help
1

Hi,

We’ve had a client today, who had been idle for +30min and his app started doing repetitively the same subscribe at a rate of roughly 100 times per minute.

It made the node process crash, then his app would connect to another node process which would then crash.

The only solution we’ve found was to ask the user to close his browser.

Have you ever seen something like it ?

We deactivated his user but his client would still send tons of requests on the websocket.

What would you suggest to block such a big number of connections ?

Best regards,

Burni

1 Like
2

Rate limiting:

// Add the rule, allowing up to 5 messages every 1000 milliseconds.
DDPRateLimiter.addRule(addCommentRule, 5, 1000);
3 Likes
3
1 Like
4

Oh great! that’s going to do the trick!!
thanks a lot!

5

Rate limiting is a necessary precaution, but I would suggest also reviewing the code where you have that subscription called to try to find out why this is happening. It might be that, for example, you are calling the subscription in some iterating component (e.g. item in a list) that in some circumstances can flood the server with subcsription requests. It would be best to prevent such a scenario in your code itself and not rely only on rate limiting.

And if you don’t need live data, then just moving to methods, as @rjdavid suggested, will solve that issue and many others in one easy move.

1 Like
6

Very interesting to check the code. I just did review the code and it really should not have looped. It’s only in the Container withTracker (export default ComponentQuotesContainer = withTracker((params) => {} ).

And when it does loop, it does not -usually re-subscribe, it reuses the same subscribe.

And it’s place where live data is required. Looking at the code, it could have happened anywhere in our code since we use similar subscribes in trackers everywhere.

Never seen that situation in the past 5 years. So far, our best theory is a wifi issue on the user’s side that triggered reconnections.

Thanks :slight_smile: :slight_smile:

7

Question regarding the rate limiter, is there a way to do an action when the rate limiter refuses a method/subs ?

I could not find one but it would be very useful in terms of monitoring.

8

It looks like I was suggesting to use a method but I was giving a link to the DDP rate limiter function that is applicable for both methods and subs :grin:

9

DDPRateLimiter.setErrorMessage(message)

Then track that message using the APM

1 Like
10

Hah, serves me right for being lazy! :slight_smile:

11

Great! thanks, that works! thanks a lot

12

Ok we’ve found a way to know a method/subscription has been refused. Simply use the callback and look at the objects received. We did not find any documentation so we named the variable just a random name for now in our tests:


let ruleIndex = DDPRateLimiter.addRule(rule_server_dynamic, oneRule.amount, oneRule.period, function (data, data2) {
     if (data.allowed === false) {
        console.log("DDPRateLimiter:REFUSED connectionId="+data2.connectionId)

    }

});

Obviously the idea is to do something "light’ not to use too much ressources.

What we designed is a rate limiter that we can update live using a json config that is read every minute. This will allow us to prevent an outage while giving us the time to investigate the code and find the culprit. This will prevent us from having to do a code update live just to set DDP rates.

Thanks for your help !!!

Regards,

Burni

1 Like