I'm sending messages over GCM with TTL=15 - and they arrive just fine. Despite that fact, the developer console (where GCM messages can be tracked) show status=expired.
According to Google's docs, expired means:
Reached their time-to-live (TTL) and expired.
Am I doing something wrong? Perhaps I'm not acking the message on my Android app?
As Reference;
time_to_live: This parameter specifies how long (in seconds) the message should be
kept in GCM storage if the device is offline. The maximum time to live
supported is 4 weeks, and the default value is 4 weeks. For more
information, see Setting the lifespan of a message.
So 15 seconds are too short to track you may want to increase this value.
Related
We launched a new mobile app for iOS and Android devices first week of January and use FCM to send push notification to users.
Thus far we've sent (based on the firebase console report) ~60k notifications out to our users and overall its a very solid and reliable platform. We split our 'sends' in groups of 1000 push tokens / devices.
Question: ~15 times since we've launched we've received 'No Result' back from the CURL that sends the notifications upstream to FCM... and on one occasion we received an error 500.
To work around this and not just assume success we are detecting when the result isn't what we expect it to be upon success, and we log the response (i.e. "no result")... then wait 5 seconds and retry, up to 3 times. (our log message denotes the 'try number' as well).
We have, maybe twice a week, received the 'first try' message (meaning the first attempt failed and 5 secs later the 2nd attempt kicks off)... and only ONCE (this week) have we received the 'second try' message...
We're wondering if this is normal behavior for FCM? Is there some paid level of support or access that would alleviate these re-try instances for us? I don't think there is an SLA for FCM, but generally speaking are others seeing this same behavior and is the rate I've described here what you'd' consider 'normal'?
Thx!
Answer received from Google today:
Hello!
If I've correctly understood this, you have sent 60k messages and received 16 failures? That comes out to around 99.9997% success. Three nines is pretty much industry gold. So looking stellar so far.
There is no paid FCM version, but all clients, regardless of payment plan, run on the best hardware available so you're already in the premium servers. : )
I would like to know what is called Message throttling in Google FCM push notification? I am trying to implement a sample push notification using FCM, but didn't understand about message throttling mentioned in their steps. There is no documentation also found about it.
https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#google-setup
Could someone clarify about this term?
This documentation of Throttling by https://stuff.mit.edu explains it really well:
To prevent abuse (such as sending a flood of messages to a device) and to optimize for the overall network efficiency and battery life of devices, GCM implements throttling of messages using a token bucket scheme. Messages are throttled on a per application and per collapse key basis (including non-collapsible messages). Each application collapse key is granted some initial tokens, and new tokens are granted periodically therefter. Each token is valid for a single message sent to the device. If an application collapse key exhausts its supply of available tokens, new messages are buffered in a pending queue until new tokens become available at the time of the periodic grant. Thus throttling in between periodic grant intervals may add to the latency of message delivery for an application collapse key that sends a large number of messages within a short period of time. Messages in the pending queue of an application collapse key may be delivered before the time of the next periodic grant, if they are piggybacked with messages belonging to a non-throttled category by GCM for network and battery efficiency reasons.
On a simpler note, I guess you can simply see throttling like a funnel that prevents an overflow of messages (normally for downstream messaging), regulating the in-flow of messages to avoid flooding.
For example, you send 1000 messages to a single device (let's also say that all is sent successfully), there's a chance that GCM will throttle your messages so that only a few would actually push through OR each message will be delivered but not simultaneously to the device.
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
Did I understood it right that in Windows Azure Queue storage a message can live for 7 days maximum?
What happens with the message after 7 days?
What happens with the message if you read it once during the 7 days and you don't delete it? I mean you read the message from the queue and set the visibility timeout to let's say 1 minute. What happens after you have read the message (without deleting it) and the 1 minutes timeout visibility expires? I know is back and available on the queue but what happens with the 7 days TTL of that message, is it renewed to 7 days from that point or is 7 days totally since message was created?
You can now opt-in to infinite TTL for Azure Storage Queue messages by specifying an expiry time of -1 seconds when initially queuing the message.
The time-to-live interval for the message, in seconds. Prior to version 2017-07-29, the maximum time-to-live allowed is 7 days. For version 2017-07-29 or later, the maximum time-to-live can be any positive number, as well as -1 indicating that the message does not expire. If this parameter is omitted, the default time-to-live is 7 days.
https://learn.microsoft.com/en-us/rest/api/storageservices/put-message#uri-parameters
Yes, you understood it correctly. Messages from queues are deleted automatically within 7 days time and there is nothing called 're-newed'. Once inserted into the queue storage, it will be deleted automatically and there is no way you can recover it back(there are no recovery tools either).
When adding a message, users specify a time to live (< 7 days) after which the message is automatically deleted if it still exists in the queue.
Maybe you need to use Windows Azure Service Bus Queue. Take a look at a great comparison between the two Queues available at Azure:
http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx
Yes 7 day is maximum. There is feeeback feature request here . You can go and comment
https://feedback.azure.com/forums/217298-storage/suggestions/4134167-infinite-ttl-for-queue-messages
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.