Client error System.Net.WebException: The request timed out

Clients C#
1

I have been troubleshooting this issue for many hours now and wonder if someone else has come across the same issue?

I have a ServiceStack server running on .NET Core 2.1 within IIS using ServiceStack 5.5.1. I then have a WPF client also running ServiceStack 5.5.1 on .NET Framework 4.8.

The WPF creates an instance of a class which contacts a single instance of JsonServiceClient within the class.The JsonServiceClient is then used in various methods within the class. The JsonServiceClient is called with async / await.

e.g.

public async Task<ObservableCollection<Customer>> GetCustomersAsync(Guid customerGuid)
{
    ObservableCollection<Customer> newItems = new ObservableCollection<Customer>();

    foreach (var item in await jsonClient.GetAsync(new GetCustomers() { CustomerGuid = customerGuid }))
    {
        Customer newItem = Customer.Create();
        iMapper.Map(item, newItem);
        newItems.Add(newItem);
    }
    return newItems;
}

Everything seems to work fine and then all of a sudden I will get a timeout e.g.

ServiceStack.AsyncServiceClient [(null)] - Exception Reading Response Error: The request timed out
System.Net.WebException: The request timed out ---> System.Net.WebException: The request was aborted: The request was canceled.
   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at ServiceStack.AsyncServiceClient.<SendWebRequestAsync>d__146`1.MoveNext() in C:\BuildAgent\work\3481147c480f4a2f\src\ServiceStack.Client\AsyncServiceClient.cs:line 259
   --- End of inner exception stack trace ---

From looking at the server logs it doesn’t appear to have reached it. But if I leave it a minute and try again it will be fine without restarting the client or server.

I found this post https://stackoverflow.com/questions/26483395/timeout-using-servicestack-client/26617316 but I have checked all my code on the server and all routes use IReturn<VALUE> or IReturnVoid. I gather this means I do not need to use a using { } statement for the jsonClient?

It is almost like there is a limit to the amount of requests that can be made as sometimes two or three jsonClient Get methods may be called at once. That steered me towards the ServicePointManager.DefaultConnectionLimit. I set this to 100 as a test in the server Startup.cs but it doesn’t make a difference.

Has anyone else experienced this? My IIS is running on Windows Server 2016, is there any special configuration required in IIS?

Thanks.

2

The Exception is thrown inside the internal implementation of GetResponseAsync():

The Exception indicates that the Request too long and was cancelled.

3

Wow, a super quick reply, thank you.

One of my routes that this happens to the most looks like this:

[Route("/GetItems")]
public class GetItems : IReturn<List<ItemDTO>>
{
    public Guid ItemGuid { get; set; }
    public Guid ItemActionGuid { get; set; }
}

I assume the request part is the /GetItems? It doesn’t take any parameters in the URL and then there are the two Guids.

The other point is that the same request works a minute later which is odd.

I also don’t think I have come across this on my dev environment using IIS Express, does that behave differently to full IIS?

Really appreciate your help! :smile:

4

.NET’s HttpWebRequest is a .NET Framework library so the same implementation gets run on all .NET Frameworks.

I can’t tell you why it’s happening, only where it’s happening and what the Exception is, i.e. basically repeating the contents of the Exception StackTrace.

One thing with Async is that it’s Task API was retrofitted on top of .NET’s HttpWebRequest APM model whereas .NET’s new HttpClient was designed around C# async/await so it’s possible using JsonHttpClient from ServiceStack.HttpClient NuGet package would be more reliable, or at least provide better diagnostics in async Exceptions.

5

Thanks for your help, i’ll try and use the new HttpClient package and see if it helps and update the post. Thanks again.

6

Hi,

I switched to JsonHttpClient and so far so good, thank you!

Is there a similar alternative to ServerEventsClient? Originally I was using my ServerEventsClient connection to do all my client requests and I was getting the same timeout error after a few requests. This is why I started using a second connection JsonServiceClient but experienced the same issue which lead me to my post.

Thanks.

7

All .NET HttpWebRequest implementations are limited by the same ServicePointManager restrictions, using different instances doesn’t avoid the restrictions.

If you’re having timeout issues you can try setting the ServicePointManager.DefaultConnectionLimit to increase the limit of concurrent connections, e.g:

ServicePointManager.DefaultConnectionLimit = 10;

If you’re still having issues you may want to look at limiting the amount of concurrent connections you’re making, e.g. making an async request for each item in a collection as in your example sends multiple I/O requests. It’s fairly inefficient to send multiple I/O requests from an unbounded collection like this. You can reduce the number of connections by batching requests, either by creating a Service that accepts multiple Customer Ids or sending an Auto Batched Request.

8

Hi, does the ServicePointManager.DefaultConnectionLimit = 10 setting work for .NET Core? I’ve read mixed messages on forums e.g. Controlling the Number of Outgoing Connections From HttpClient (.Net Core or Full Framework) | Microsoft Learn

This is interesting, I will take a look at this feature:

Thanks again.

9

No it doesn’t, in .NET Core the HttpWebRequest was rewritten to be a wrapper over HttpClient.