1

Azure notifications hub shows that from 13k WNS toast notification broadcast only 5k messages succeeded and 8k got "WNS Channel Disconnected" errors. What can cause such large amount of errors? What can I check, and why this happens?

saniokazzz
  • 476
  • 1
  • 6
  • 21

1 Answers1

2

It can be because of channel is no longer valid and should be refreshed. Push notifications are tough to debug. Could you please say what is the time period of that "13k push"?

Also check the WNS overview - it has the "Important notes" section https://msdn.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-windows-push-notification-services--wns--overview

There is a useful page as well about debugging Notification Hubs: https://msdn.microsoft.com/en-us/library/azure/dn530751.aspx

So i would go with the checking if channel is even valid.

Alex Belotserkovskiy
  • 4,012
  • 1
  • 13
  • 10
  • Thank you for answer. I think I have checked everything that possible on MSDN. There were 26 broadcast notifications, one every hour for different users timezones. I have ~21k active devices total in that notification hub. For expired channels I have got 1.5k "WNS Expired Channel Error" errors, that's ok I think. The main problem is that I thought, Azure will retry sending notifications to disconnected devices, and once they will be connected, they will get it. Maybe you can advice, if there is any retry mechanism I can use? – saniokazzz Apr 13 '16 at 06:11
  • Hi, sorry for the delay. Azure NH are using the back off strategy - https://azure.microsoft.com/en-us/documentation/articles/notification-hubs-diagnosing/#pns-issues and start to drop push after 30 min. Regarding offline devices - NH will store only the last non-delivered push. Does it looks like something that can occur in your situation? BTW, it is useful to test it using Service Bus Explorer and see how many errors you have. Do you have the possibility to do that? – Alex Belotserkovskiy Apr 13 '16 at 19:57
  • Oops, beg my pardon - i missed the question about retry logic. I would offer you to implement the similar back-off strategy with the logic of detecting the status and outcome of the push. https://blogs.windows.com/buildingapps/2013/10/22/recommended-practices-for-using-microsoft-push-notification-service-mpns/ – Alex Belotserkovskiy Apr 13 '16 at 20:01
  • Thank you for effort. I have enabled Standard plan to see rich Telemetry for every notification. But for broadcast notifications I think I need some redesign, to have Channel URI's on my back-end and send message for each person, then to track it's status. Because now I can see only counts of delivered/failed messsages. I have tried using Service Bus Explorer, but getting 500(Internal server) error always when connected to Service Bus Namespace, but I will try to figure out how to fix that. – saniokazzz Apr 15 '16 at 05:50
  • 1
    There's no reason to implement retry for disconnected devices. WNS will cache up to 5 toasts and tiles per channel, or 1 raw notification when a device is offline. Retrying a notification for a disconnected device on toasts especially could just result in duplicate notifications. Retry is only needed if you get a 500 or 503 error from the service, or a 406 error (meaning your notification is being throttled). In all cases, make sure you're using exponential backoff on your retries or you'll only make the throttling worse. – Stacey Hanson Apr 15 '16 at 17:56