ServiceStack client request timeout with .Net 6

1

I’ve just upgraded one of my projects to .Net 6 and am encountering a new 5 minute timeout when calling from one asp.netcore app to another. Here are the details :

  1. Both services are managed by IIS but are both running Out of Process (Kestrel)

  2. Both services are run with

    <aspNetCore requestTimeout="00:30:00" ...> in their web.config

  3. The Calling code uses a proxy and sets the Timeout there:

        public static JsonServiceClient Client => new JsonServiceClient(ServiceStack.HostContext.AppSettings.GetString("AppSettings:API.URL"))
        {
            Timeout = TimeSpan.FromMinutes(30)
        };

  1. The error received calling side is:

    " An error occurred while sending the request "

  2. The Timeout is observed as 5 minutes

    7/26/2023 6:33:11 PM, ImportStats: Step: 1
    7/26/2023 6:38:11 PM, WEB ImportStats: An error occurred while sending the request.

Any thoughts on where the timeout is coming from and how to configure it would be appreciated.

Regards.

2

@Matt what version of IIS are you running? and do you have any other network infrastructure between the clients and the IIS server like firewalls, proxy server etc that might have its own timeouts?

You could try catching the exception to see if there are any more details to the error? Alternatively you could use Postman or another similar tool to recreate the same HTTP call and you should see the full payloads, some network infra will put more info in headers that can point to a root cause if it is something external to your application/IIS.

It’s been a while since I’ve used IIS, but there use to be various timeouts that were controlled by hard to find registry keys, might be worth doing a search for any defaults related to the version you are running that are 5 minutes.

3

Hi, it is IIS 10, and no, the two services are running on the same machine. Thanks for your thoughts, this is where I am heading. I’m going to run both services from command line and see if I can recreate the same issue to determine if its IIS or Krestral.

4

Probably unlikely, but might be worth double checking, at least to rule it out, how the other API URL is resolving via AppSettings:API.URL when running on that box. Eg via a tracert to see if traffic is indeed isolated to the single machine.