0

I can't find any definitive answer here. My IoT service needs to tollerate flaky connections. Currently, I manage a local cache myself and retry a cloud-blob transfer as often as required. Could I replace this with an Azure EventHub service? i.e. will the EventHub client (on IoT-Core) buffer events until the connection is available? If so, where is the info on this?

GGleGrand
  • 1,565
  • 1
  • 20
  • 45

1 Answers1

1

It doesn't seem so according to: https://azure.microsoft.com/en-us/documentation/articles/event-hubs-programming-guide/

You are resposible for sending and caching it seems:

Send asynchronously and send at scale

You can also send events to an Event Hub asynchronously. Sending asynchronously can increase the rate at which a client is able to send events. Both the Send and SendBatch methods are available in asynchronous versions that return a Task object. While this technique can increase throughput, it can also cause the client to continue to send events even while it is being throttled by the Event Hubs service and can result in the client experiencing failures or lost messages if not properly implemented. In addition, you can use the RetryPolicy property on the client to control client retry options.

Erik Oppedijk
  • 3,496
  • 4
  • 31
  • 42
  • Thanks for finding this. IMHO, real-world IoT must tollerate connection failures without data loss, so I'll stick to my Brokered Service Bus solution and check the RetryPolicy mentioned to see if can queue/cache multiple messages for me and retry until the connection exists. – GGleGrand Dec 31 '15 at 12:22
  • ... see if anybody has more info before I mark as answered. – GGleGrand Dec 31 '15 at 12:30
  • No problem, even with MQTT there doesn't seem to be a client cache. The protocols for IoT focus on an online scenario, being offline will be different for each device and application, so no solution there I guess. – Erik Oppedijk Dec 31 '15 at 13:38
  • This seem to be the extent at the moment: https://azure.microsoft.com/en-us/documentation/articles/best-practices-retry-service-specific/ Retry is not the same as buffering, but may be adequate in some cases. ServiceBus appears to have the best cards here. No mention of Event Hub. – GGleGrand Jan 04 '16 at 15:50