Kevin Lam

My feedback

  1. 118 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
      Password icon
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      6 comments  ·  Scheduler » Features  ·  Flag idea as inappropriate…  ·  Admin →
      under review  ·  Kevin Lam responded

      Mr. Andersson,
      To be clear, do you mean the retry policy for an HTTP request (which includes the timespan between retries and the number of retry attempts to make)?

      Thanks,
      Kevin

      Kevin Lam commented  · 

      Mr. Andersson,
      We do not expose the capability of changing the HTTP request timeout in the API. You may be getting that confused with the timespan between retries or perhaps it's just a terminology confusion. Exposing the configurability of the number of retries and retry interval in the portal is definitely in our plans.
      If you really did mean HTTP request timeout then it would be helpful to know what timeout you would need. Today this is not configurable as it has a more direct affect on COGs. We typically recommend for requests that have a long processing time to make the HTTP processing asynchronous and respond immediately with a 202.

      Thanks,
      Kevin

    • 62 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
        Password icon
        Signed in as (Sign out)
        You have left! (?) (thinking…)
        9 comments  ·  Scheduler » API & SDK  ·  Flag idea as inappropriate…  ·  Admin →
        under review  ·  Kevin Lam responded

        It would be helpful to hear which variables would be most useful to everyone by adding them to the comments of this suggestion.

        Thanks,
        Kevin

        Kevin Lam commented  · 

        Thanks for the suggestions.
        The same information that is passed in as part of the body of a Storage Queue Message is available as headers in HTTP requests.
        HTTP Headers included in each request from Scheduler:
        x-ms-execution-tag
        x-ms-client-request-id
        x-ms-scheduler-expected-execution-time
        x-ms-scheduler-jobid
        x-ms-scheduler-jobcollectionid

        The execution-tag can be used to identify the instance of the request and the client-request-id is unique with every call made. These can be used to help with idempotent processing.

        -Kevin

      Feedback and Knowledge Base