Update: Microsoft will be moving away from UserVoice sites on a product-by-product basis throughout the 2021 calendar year. We will leverage 1st party solutions for customer feedback. Learn more here.

JeffC

My feedback

  1. 71 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Azure Functions » Feature  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    JeffC commented  · 

    Agree. gRPC is important and I've had several projects face choosing between gRPC vs Azure App Services and Azure Functions because those services don't support gRPC.

    It is my understanding that the problem is due to lack of support in Http.sys for HTTP/2 response trailers which are required for using gRPC.

    I believe a big part of the problem is that we're dealing with multiple MS teams here. There is a version of Http.sys in Windows Server vNext insider builds that is compatible with gRPC HTTP/2 requirements.

    Great! But does that mean we have to wait until there's a new Windows server release? And likely some time after that as the App Services team will need time to prepare and test its version(s).

    My thoughts are the someone at MS should have seen this coming a long time ago and gotten the compatible Http.sys into earlier server builds.

    JeffC supported this idea  · 
  2. 1,218 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    25 comments  ·  Web Apps » App Service Environment  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    JeffC commented  · 

    Just had another project defer gRpc because of lack of support on Azure App Services.

    I'm getting more and more interest in moving to gRpc architectures but many project owners don't want to sacrifice using App Services.

    An error occurred while saving the comment
    JeffC commented  · 

    Unfortunately we've already had to skip on gRPC for a project because it won't run on Azure App Service.

    And there's another where the owners are considering now not using Azure App Service because they really want gRPC.

    I'll probably be facing more of these opportunities next year. I'm hoping that there will be progress on this at some point in the near future.

    An error occurred while saving the comment
    JeffC commented  · 

    This is holding up several projects to move from rest to grpc. (Because we require rest fallback for some older consumers)

    JeffC supported this idea  · 
  3. 26 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    JeffC commented  · 

    AT TIME ZONE is slow enough that I just avoid it and use .NET TimeZoneInfo methods to convert at the client application.

    If SQL could deliver the performance at least equal to client applications using TimeZoneInfo I'd be included to use it frequently.

    JeffC supported this idea  · 
  4. 9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    JeffC supported this idea  · 
  5. 170 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    8 comments  ·  Azure Cosmos DB » SQL API  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    JeffC commented  · 

    This would be extremely helpful. We have to use DateTimeOffset for proper date handling and display throughout our application and SQL Server does it quite well. But I want to move part of our application over to Cosmos DB and can't do it until there is support for DTO.

    JeffC supported this idea  · 
  6. 65 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  Azure Functions  ·  Flag idea as inappropriate…  ·  Admin →
    JeffC supported this idea  · 
    An error occurred while saving the comment
    JeffC commented  · 

    I can see how this would be useful in some situations. I guess you'd have to have a setting for the max number of items to fetch from SB. Then your main function method (Run) would need to have the arguments expect a list of message objects.

  7. 112 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    6 comments  ·  Azure Functions  ·  Flag idea as inappropriate…  ·  Admin →
    JeffC supported this idea  · 
    An error occurred while saving the comment
    JeffC commented  · 

    For sure Azure SQL. We're using Service Bus as a go between now but it would be better to have a SQL trigger.

  8. 88 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    12 comments  ·  Azure Functions  ·  Flag idea as inappropriate…  ·  Admin →

    Here’s the latest as there seem to be 2 types of ask here and so two seperate updates. Need comments for if this issue should close to be focused on one or other:

    1. I want to control how many calls my function can make to another API (the 3rd party API rate limiting).
    – In all plans we now have a way to specify the max instances. This can limit how far a function app instance can scale: https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#limit-scale-out

    2. I want to stop my function from triggering more than x times an hour.
    Nothing planned in this in the short term. Using API Management for HTTP functions with throttles would be our recommendation for HTTP, nothing out of box for non-HTTP triggers yet.

    JeffC supported this idea  · 
    An error occurred while saving the comment
    JeffC commented  · 

    I'd like to have this ability to protect our functions from misuse.

  9. 16 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Service Bus  ·  Flag idea as inappropriate…  ·  Admin →
    JeffC shared this idea  · 
  10. 245 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  10 comments  ·  Scheduler » Features  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    JeffC commented  · 

    This is the #1 missing feature that prevents me from going live with Azure Scheduler. I have jobs that need to run at specific local times across timezones all around the world.

    Examples: job1 run at 3am PST Los Angeles, job2 run at 3am EST New York, job3 run 3am IST Dublin.

    For a scheduler to work for our needs there must be the ability to schedule the job to run in a specific timezone and then the scheduler must account for daylight savings time to be sure the job always runs at the correct local time.

    We are using a home grown scheduler that is short on features and I'd like to leave it to run on Azure but timezone and DST support is a showstopper for us. Our homegrown system has been able to handle this for years. A few lines of C# can handle the conversion between future job schedule time and UTC and will account for what the target timezone DST offset will be (if any) at the scheduled date and time.

Feedback and Knowledge Base