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
Related
We are sending lots and lots of FCM Messages to our millions of users. As the message is triggered by an external event (Kick off in a football match) we sent many messages at the same time.
Sometimes the sending of an FCM message fails and we get an error message like this:
<H1>302 Moved</H1> The document has moved
<A HREF="https://fcm.googleapis.com/batch?
google_abuse=GOOGLE_ABUSE_EXEMPTION%3DID%....3B+expires%3DTue,+22-Nov-
2022+19:04:17+GMT">here</A>. </BODY></HTML>
(I removed some text for privacy reasons.)
For sending the messages we use
implementation 'com.google.firebase:firebase-admin:9.1.0'
We got thousands of error messages like this in one minute. In the next minute everthing worked fine again.
I have search the internet for information about it. But i couldn't find any abuse rules for FCM. Does anybody has information about this kind of error?
firebaser here
At first glance, your project may be getting throttled, but it may also be another problem in the API calls or the FCM backend. It’ll be challenging to pinpoint or even narrow down what is the specific cause of the error on a public forum without going into project-specific details. I would recommend reaching out to Firebase support as they can offer personalized help. Please provide the latest request and response (with timestamp) you have so they can check what happened to the message delivery.
We are sending push notifications to Android devices via GCM API.
People are allowed to subscribe to different topics and receive alert every couple of days.
There is between 100_000 to 1_000_000 users subscribed for given topic, so we wanted to speed things up using more than ten connections.
We see answers with retry, so we retry after specified period of time as stated in the docs.
Can we get rid of retires by using more connections and sending the requests slower?
Or is the quota set for given API key and starting more connections will even hurt us?
EDIT:
We are using GCM HTTP interface. To be precise erlang-gcm library: https://github.com/pdincau/gcm-erlang We are sending message to 1M users. We are not sending to topic. We are performing multicast send to list of users. gcm-erlang library allows us to pass 1000 users per request (which is also the limit of GCM API). This means, we have to perform at least 1000 requests.
It takes something around 10 minutes to process all those 1000 requests, so we wanted to make them in parallel, but it doesn't make it faster. Here I've found information on throttling: https://stuff.mit.edu/afs/sipb/project/android/docs/google/gcm/adv.html#throttling
"Messages are throttled on a per application"
Does it mean, that even if this are messages to different users, we are still throttled, because they are using single API key for our mobile application?
Will the XMPP endpoint faster?
It is weird that parallelizing requests didn't make them faster. How come? Are you sure that the bottleneck is not on your side?
No, it doesn't look like you're throttled (you would receive errors if you were instead of waiting on line)
I still don't understand why topics don't work for you. They seem like a good match.
Anyway, if you want to send messages individually, I would highly recommend switching to XMPP. You will be able to send one hundred messages at a time per connection and open up to 1000 connection (but you're not gonna need that much really).
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
I'm getting 406 Not Acceptable as response when I try to send a push notification, I understand the problem and I've fixed the code that was causing it but I'm not quite sure how to make the error go away, the server responds with 406 to every one of my requests for push notifications. Will this happen by itself after a period of time or? Thanks.
This isn't an error you should (or could) do something about. It just means that you sent too many notifications to the same device or too many notifications per second, and you have to wait until you can send more.
406 Not Acceptable
This error occurs when an unauthenticated cloud service has reached the per-day throttling limit for a subscription, or when a cloud service (authenticated or unauthenticated) has sent too many notifications per second. The cloud service can try to re-send the push notification every hour after receiving this error. The cloud service may need to wait up to 24 hours before normal notification flow will resume.
(Source)
Fixed itself after a while, half a day or so.
Getting this WCF error, and no idea how to fix it:
System.ServiceModel.CommunicationException: The sequence has been terminated by the remote endpoint. The user specified maximum retry count for a particular message has been exceeded. Because of this the reliable session cannot continue. The reliable session was faulted.
Any ideas welcome :(
From the error message, it would appear that you're using reliable messaging. One of its features is that if a message transfer fails, it will be retried - up to a maximum number of attempts.
Obviously, in your setup, this max number has been maxed out. This might indicate a problem with the network, or your service code, or both. Really hard to tell from here without knowing what you're doing and what your setup is......
I guess the main question would be: do you really need the reliable messaging feature? What are you trying to achieve with this? If you could turn it off, you wouldn't be seeing those errors... can you switch to some other mechanism, maybe message queueing (MSMQ)? Or can you rearchitect your app so you can live with the odd chance that one message might get delivered "out of band" ?