none
Azure Function behaviour in regards to async code RRS feed

  • Question

  • I have an HTTP triggered Azure Function. The usual, it accepts some data, authenticates the user and then sends the user some data back. The scenario is as following. Some of the data the user is sending needs to be persisted, but I don't need or want the user to wait for that. For example, let's say it is the user's last location.

    I moved the code that persists the user location into an async method, and I just don't wait on it. The result is, the user client receives an HTTP response before the persistence code runs, so it seems to work. My question, is is this a valid scenario or just something that happens to work ?

    On a related note, if an Azure Function reaches its max 5 minute execution time, is there some mechanism where it can warn the code it is going to be terminated forcefully ?

    Sunday, April 30, 2017 9:07 AM

Answers

  • When returning before your data is persisted, just make sure that you handle any exceptions or timeouts in your async method.  In the event that the data is not persisted, you should ensure that your code has a way to track that.  As mentioned by @RomanKiss, you could log the missed write to a ServiceBus queue.

    As for your second question, there is currently no mechanism to warn you that your code is going to be terminated due to the 5 minutes max execution time.


    • Edited by Ling Toh Monday, May 1, 2017 6:18 AM
    • Marked as answer by Shrulik Monday, May 1, 2017 10:23 AM
    Monday, May 1, 2017 5:47 AM

All replies

  • Hi,

    I do recommend to use a Service Bus Queue for async process, see the following screen snippet:

    Thanks

    Roman



    • Edited by Roman Kiss Sunday, April 30, 2017 5:33 PM
    Sunday, April 30, 2017 5:31 PM
  • When returning before your data is persisted, just make sure that you handle any exceptions or timeouts in your async method.  In the event that the data is not persisted, you should ensure that your code has a way to track that.  As mentioned by @RomanKiss, you could log the missed write to a ServiceBus queue.

    As for your second question, there is currently no mechanism to warn you that your code is going to be terminated due to the 5 minutes max execution time.


    • Edited by Ling Toh Monday, May 1, 2017 6:18 AM
    • Marked as answer by Shrulik Monday, May 1, 2017 10:23 AM
    Monday, May 1, 2017 5:47 AM
  • For long running tasks, I agree with you. But have all this overhead for an operation that would rarely take more than a second and never more than a few seconds, seems illogical. Even more so, when it isn't business critical the information is persisted. 

    But for a user facing API call the difference between 1.3 seconds and 0.3 is significant.

    Monday, May 1, 2017 10:27 AM
  • I have a whole "interceptor + ApplicationInsights" thing going on, so I'm okay on the track errors front.

    I think I found a way to do the second thing. I haven't tested it out yet, but it should be possible to ask the AzureFunction for an injected CancellationToken, on which I can define callbacks.

    Source : http://stackoverflow.com/a/36793812/657657

    Monday, May 1, 2017 10:31 AM
  • Hi Ling & Shrulik,

    - my picture shows a message exchange pattern from the Request/Response to the OneWay (Fire&Forget), where the first AFN (Http Trigger) will create a message for its post-processing and send it to the Azure Service Bus Queue in the transactional atomic manner. Once the message has been pushed into the queue, the AFN can be returned back to the caller. The duration of the Http AFN is very short and its processing is not critical for any heavy load.

    The second AFN such as SBQ Trigger will process a storing data in the transactional manner based on the needs. 

    Thanks

    Roman



    • Edited by Roman Kiss Monday, May 1, 2017 1:36 PM
    Monday, May 1, 2017 1:35 PM