Can someone tell me what the behaviour is when a Graph change notification is attempted to be sent to the configured endpoint (notificationUrl) but the endpoint is unavailable (e.g. your in the process of a release or the endpoint is just not there for a while)?
I can see that I am getting a repeated notification delivery attempt every 5 minutes, but does that eventually stop? Does it become a 'missed' lifecycle event at some stage? Or does it keep trying endlessly?
thanks
The service will retry for a few hours.
If the notification URL is unresponsive or slow for more than 10% of delivery attempts, notifications will be paused and retried in a couple of hours.
If the notification URL is unresponsive or slow for more than 20% of delivery attempts, notifications will be dropped.
Unresponsive notification URL will not result in a missed lifecycle notifications. Those are only sent when the service was not able to emit notifications due to other reasons.
Related
I want to make an application exactly like the title. Every 5 or 15 minutes in the background, I will send a request to the api which I made and send a notification to my phone according to the results.
I used the react-native-notifications and react-native-background-timer plugin but when I lock my phone or close the app, notifications are not received. (IOS)
I struggled for a week, I couldn't do it.
I'm waiting for your help.
I'm working on a sync server that keeps the Office 365 events and my calendering app in sync. I subscribed to a push notification for user's event calendar that has a custom single extended property.
The documentation says if the sync server doesn't respond with a 2xx message, the notifications will be resent in periodic intervals. I tried by bringing my server down for some time and in this interval I did some changes to the events for which I was expecting notifications. Then I brought the server up again and it took some time(10-15 mins) for Microsoft to send old queued notifications.
Any idea what is the interval that Microsoft sends queued notifications when 2xx is not received?
I have set up a microsoft graph webhook to monitor changes in messages, with my application, that was working great in production.
What is happening is the webhook is not sending notifications as quickly as I would expect it to send its notifications. Sometimes it is immediate, sometimes it takes an hour, I do not understand why this is happening.
Any help would be much appreciated.
Webhooks subscriptions expire after a certain time and/or if your webhook crashes often or takes too long to reply on regular basis.
You need to renew your subscription on regular basis in order to keep it going.
You can find more information about that here https://www.eliostruyf.com/creating-and-renewing-your-microsoft-graph-webhook-subscriptions/
I don't think you should be expecting any guaranties that the notification will be instantaneous (or almost). The reason is all that works with a message queue pattern and a reduce pattern behind the scenes. Notifications are async, and can be delayed depending on the service, on the number of notifications to go to the same subscriber and so on
We use push notifications in our app. They work, but there's some variable delivery delay (sometimes ~10seconds, sometimes more than minute).
Does anybody know what to do to minimize those delays?
I know APNS has some delay, but I've never experienced such slow deliveries.
EDIT:
I digged out some time delay between message sent date and push created date.
I have message sent at 12:40:17 (according to QB's admin panel)
and push notification log for the same message says the the push is: "created_at":"2016-05-12T12:40:28Z"
Clearly we have 11 seconds difference between the time message is sent to QB and push notification being sent to APNS from QB
Push notifications are unreliable and cannot be guaranteed that they have been delivered. It all depends on the apple APNS server, that said, usually when I send a push notification I get the result in under a few seconds.
They are not reliable! ****There is no guarantee that push notifications will actually be delivered, even if the APNS server accepted them****.
As far as your server is concerned, push notifications are fire-and-forget; there is no way to find out what the status of a notification is after you’ve sent it to APNS. The delivery time may also vary, from seconds up to half an hour.
Also, the user’s iPhone may not be able to receive push notifications all the time. They could be on a WiFi network that does not allow connections to be made to APNS because the required ports are blocked. Or the phone could be turned off.
APNS will try to deliver the last notification it received for that device when it comes back online, but it will only try for a limited time. Once it times out, the push notification will be lost forever!
For what it's worth I am running into this issue too with Quickblox. The push notifications, a critical part of the communication flow, are delayed by up to a minute or so. I use push all the time in enterprise apps and yes, they should not be considered reliable, but in practice APNS communications are remarkably reliable and near instantaneous in my experience. It seems like Quickblox is queuing (throttling?) notification requests, my guess is to conserve bandwidth - aren't they based in Russia? It's spoiling what would otherwise be a great product.
Is it possible to send multiple (10 - 15) notifications to the registered iOS users at a time / instantaneously ? What are the limitations for iOS Push Notifications ?
Is it possible to send multiple (10 - 15) notifications to the registered iOS users at a time / instantaneously ?
No you can not send 10-15 notification simultaneously to same user, read more here at apple docs .
If you are sending multiple notifications to the same device or
computer within a short period of time, the push service will send
only the last one.
However if you intend to send push notifications to different users at same time than it should be no problem (Which i guess is what you are looking for).
What are the limitations for iOS Push Notifications ?
If you are not sending them simuntanously to same user than there is no limitation for APN's push notification as mentioned here .Take a look at Push Notification Throughput and Error Checking
There are no caps or batch size limits for using APNs. The iOS 6.1
press release stated that APNs has sent over 4 trillion push
notifications since it was established. It was announced at WWDC 2012
that APNs is sending 7 billion notifications daily.
If you're seeing throughput lower than 9,000 notifications per second,
your server might benefit from improved error handling logic.
Here's how to check for errors when using the enhanced notification
format. Keep writing until a write fails. If the stream is ready for
writing again, resend the notification and keep going. If the stream
isn't ready for writing, see if the stream is available for reading.
If it is, read everything available from the stream. If you get zero
bytes back, the connection was closed because of an error such as an
invalid command byte or other parsing error. If you get six bytes
back, that's an error response that you can check for the response
code and the ID of the notification that caused the error. You'll need
to send every notification following that one again.
Once everything has been sent, do one last check for an error
response.
It can take a while for the dropped connection to make its way from
APNs back to your server just because of normal latency. It's possible
to send over 500 notifications before a write fails because of the
connection being dropped. Around 1,700 notifications writes can fail
just because the pipe is full, so just retry in that case once the
stream is ready for writing again.
Hope this helps.
If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one.
Here's why. The device or computer acknowledges receipt of each notification. Until the push service receives that acknowledgment, it can only assume that the device or computer has gone off-line for some reason and stores the notification in the quality of service (QoS) queue for future redelivery. The round-trip network latency here is of course a major factor.
As described in the Local and Push Notification Programming Guide, the QoS queue holds a single notification per app per device or computer. If the service receives another notification before the one in the queue is sent, the new notification overwrites the previous one.
All of this points out that the intent is that a notification indicates to an app that something of interest has changed on the provider, and the app should check in with the provider to get the details. Notifications should not contain data which isn't also available elsewhere, and they should also not be stateful.
Any push notification that isn't delivered immediately was queued for future redelivery because your device was not connected to the service. "Immediately" of course needs to take latency for your connection into account. Outlying cases would be beyond 60 seconds as APNs will time out at that point.
for more info click here