Share via

Azure iot hub

51155945 0 Reputation points
2026-03-23T07:08:51.1733333+00:00

I’m using the Azure SDK. I print the elapsed time before sending and after sending to measure how long it takes.Below is my code. The printed duration is over 50 seconds. Why does the response take so long? Could you help investigate the cause? Is it because the C2D throttling rule was triggered?

Message messageToSend = new Message(content);

messageToSend.setDeliveryAcknowledgement(DeliveryAcknowledgement.Full);

Map<String, String> map = new HashMap<>();

map.put("topic", topic);

messageToSend.setProperties(map);

serviceClient.send(sn, messageToSend);

long duration = System.currentTimeMillis() - startTime;

logger.info("Send message to device by azure producer success, sn:{} topic:{} content :{} duration:{} ms", sn, topic, content, duration);

Azure IoT Hub
Azure IoT Hub

An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. SRILAKSHMI C 17,875 Reputation points Microsoft External Staff Moderator
    2026-03-24T12:36:25.07+00:00

    Hello 51155945,

    Welcome to Microsoft Q&A and Thank you for reaching out,

    Based on the details you’ve shared, the ~50-second delay you’re observing is expected behavior and is primarily caused by the use of DeliveryAcknowledgement.Full, rather than any throttling issue.

    Root cause

    When you set:

    messageToSend.setDeliveryAcknowledgement(DeliveryAcknowledgement.Full);

    the serviceClient.send() call does not return immediately. Instead, it waits for the complete delivery cycle:

    1. IoT Hub accepts the message
    2. The message is delivered to the device
    3. The device processes the message
    4. The device sends an acknowledgment back to IoT Hub

    Only after all these steps are completed (or a timeout occurs) will the call return.

    Why ~50–60 seconds delay occurs

    If your device is:

    • Not continuously connected
    • Using HTTP polling instead of persistent connection
    • Slow to receive or process messages

    then IoT Hub waits for the acknowledgment until it times out (typically around 60 seconds). This aligns with the ~50-second duration you’re seeing.

    Is this due to C2D throttling?

    No, this is not related to Cloud-to-Device (C2D) throttling.

    If throttling were the issue, you would see:

    • Explicit errors (e.g., HTTP 429 / quota exceeded)
    • Failed or rejected requests

    Instead, your request is succeeding but waiting indicating acknowledgment delay, not throttling.

    Recommendations

    To improve performance and reduce latency:

    Adjust acknowledgment mode: If device-level confirmation is not required, switch to:

    • DeliveryAcknowledgement.None → returns immediately after IoT Hub accepts the message
    • DeliveryAcknowledgement.OnArrival → waits until IoT Hub queues the message

    This will reduce latency from ~50 seconds to near real-time.

    Ensure device connectivity:

    • Use MQTT or AMQP (persistent connections) instead of HTTP polling
    • Make sure the device is online and actively listening for C2D messages

    Validate device-side processing:

    • Confirm how quickly the device receives and acknowledges messages
    • Any delay on the device side directly impacts the send call duration

    Enable diagnostics and logging:

    • Enable SDK-level logging to inspect request/response timing
    • Review IoT Hub metrics for delivery status and errors

    The delay is caused by DeliveryAcknowledgement.Full, which makes the send operation wait for the device acknowledgment. If the device is not immediately available or responsive, the operation blocks until timeout (~60 seconds). This is expected behavior and not due to throttling.

    To achieve faster response times, consider using a less strict acknowledgment mode or ensure the device is continuously connected and processing messages in real time.

    Please refer this

    • Lab :: Azure IOT Hub Source – https://supportability.visualstudio.com/Fabric/_wiki/wikis/Fabric/1210506/Fabric Experiences/Real-time Analytics – Event streams/Trainings/Labs/Lab :: Event Stream Sources/Lab :: Azure IOT Hub Source

    • Issues with Azure Security Center and IoT Hub – https://docs.microsoft.com/azure/asc-for-iot/troubleshoot-agent

    • Problems related to the Azure Stack Portal or CLI – https://docs.microsoft.com/azure-stack/user/iot-hub-overview?view=azs-2005

    • Issues connecting a device to IoT Hub for the first time – https://docs.microsoft.com/azure/iot-hub/tutorial-connectivity

    • Other issues (IoT Hub SDK reference) – https://docs.microsoft.com/azure/iot-hub/iot-hub-devguide-sdks

    • Issues with Event Grid and IoT Hub – https://docs.microsoft.com/azure/iot-hub/iot-hub-event-grid

    I Hope this helps. Do let me know if you have any further queries.

    If this answers your query, please do click Accept Answer and Yes for was this answer helpful.

    Thank you!

  2. Q&A Assist
    2026-03-23T07:09:09.3766667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    serviceClient.send(...) is a synchronous call over AMQP that includes network latency, IoT Hub routing, and (optionally) waiting for delivery acknowledgments. The elapsed time measured around this call is the end-to-end time for the SDK to send the C2D message to IoT Hub and receive the service response, not just local processing time.

    From the documented behavior:

    • Cloud-to-device messages are sent from a backend app through IoT Hub to the device using the service SDK (for Java, C#, Node.js, Python, etc.).
    • The SDK uses AMQP and a service client (ServiceClient in C#, equivalent in Java) to send the message.
    • Message delivery and feedback are affected by IoT Hub configuration such as message TTL, feedback retention, and delivery attempts, but these are about how long IoT Hub will keep trying to deliver to the device, not about the latency of the send API call itself.
    • Throttling and retry policies are not shown in the provided context, and the article explicitly notes that retry policies are not demonstrated and should be implemented separately for production.

    The context does not state that C2D throttling would cause a single send call to block for ~50 seconds. It only states that:

    • The backend app sends a C2D message via the service client.
    • Delivery feedback can be requested and processed separately via a feedback receiver.
    • Message retention time, retry attempts, and max delivery count are configurable and affect delivery/feedback behavior.

    Given the available information, the 50+ second duration is attributable to the synchronous nature of the send call plus network and service processing time, not to documented C2D throttling behavior. To avoid blocking the calling thread, the recommended pattern is to use the asynchronous send APIs (for example, sendAsync in C#) and handle delivery feedback via the feedback receiver rather than measuring around a synchronous call.

    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.