When I send replicate topic message(10 times per 2 second) at short time, after that it seem gcm would delay to send message no matter what I send.
The gcm format
collapse_key:"..."
data:{...},
dry_run:false,
http://www.androiddocs.com/google/gcm/adv.html#throttling
Throttling topic
and the answer could found at
GCM: how to avoid throttling
Related
I'm reciving error "Topic quota exceeded" when trying to send a push.
I thought Firebase Cloud Messaging doesn't had limitations, what I' doing wrong?
As for as I know there is no limitations. you can reach 1000 at once. But If you are over that firebase will need some more time to send to everyone. Even If you use own server to send push notification it will be same
The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a "quota exceeded" response.
There is no limit for topics, but there is a time limit for processing those after crossing certain number. FCM limit the number of concurrent message fanouts per project to 1,000. After that, FCM may reject additional fanout requests or defer the fanout of the requests until some of the already in progress fanouts complete. I attached the related DOCS below, please go through that for more info.
Same question on a forum
Topic messaging
Fanout Throttling
We have a website that works with two million users. When we have new events on the website we send an FCM notification to our user's mobile app. But the website does not have enough resources for lots of users at once.
Can we send FCM messages to a topic chunk by chunk or deliberately decrease the fanout rate and put a delay between each fanout?
What is your suggestion?
There is no way to control the fanout rate of topics in Firebase Cloud Messaging.
The only options I can think of are to:
Create a number of more specific topics (e.g. topic-001, topic-002, ... topic-100), subscribing each client to one of the topics randomly (a form of sharding), and then sending a message to each topic in turn with a delay in between them.
Using a data only message, and delaying the display in your application code by a random amount.
No longer using topics but delivering straight to FCM tokens in your code, so that you fully control when each individual message gets sent.
From documentations,
we can get TOO_MANY_SUBSCRIBERS error, when try to send push message to topic.
Are messages sent or topics stop working?
From this point we need to send messages using tokens?
Should we use tokens instead of topics from the beginning?
Is this error comes only to server?
If yes, why it's recommended to unsubscribe device from topic?
Is it possible to catch this error at the client?
Is there any way of knowing in an QuickBlox app if a message has been throttled due to sending too many messages per second.
I set up a test and sent enough messages to cause throttling, but I can not find any error function or callback that gets called when this happens - it seems the messages are just silently discarded. If this is the case, then it makes me very wary of using QuickBlox.
Gary
You can send as many messages as you can and need
In case of throttling you will be disconnected from Chat, but it's a big limit to reach it
I have implemented GCM CCS server-client architecture. The problem is sometimes I receive a message multiple times, even though the first time I ACK it, like I do with the rest of the messages. What could be the problem ?
Note that the message I receive multiple times has the exact same XMPP stanza every time, nothing changes (ex, even same message_id, so it's like GCM never received my ACK for the first time).
So apparently this just happens. Why ? No f*cking idea. The explanation would be that the initial ACK sent from the server to the GCM server is not received, thus GCM sends the message again. In conclusion, just take care in the code for duplicate messages to be on the safe side. Quite pathetic, but whatever.
Pls see..
"If the connection between CCS and the device is poor, GCM may send multiple, duplicate delivery receipts. You can safely ignore such duplicates."
https://developers.google.com/cloud-messaging/ccs