Asynchronous task blocked on a synchronous call

[csrivaab-jci]

Description

Package version - 3.4

I getting the following two issues intermittently while the application startup...

1. 2 threads are performing asynchronous work in method 'GraphQL.dll!GraphQL.Http.HttpResponseStreamWriter.FlushInternal(bool)', but are waiting on a synchronous call to method 'System.Private.CoreLib.dll!System.Threading.ManualResetEventSlim.Wait(int, System.Threading.CancellationToken)'. This may cause thread pool starvation and hangs.

2. 10 threads are performing asynchronous work in method 'Newtonsoft.Json.dll!Newtonsoft.Json.JsonTextReader.ReadData(bool, int)', but are waiting on a synchronous call to method 'System.Private.CoreLib.dll!System.Threading.ManualResetEventSlim.Wait(int, System.Threading.CancellationToken)'. This may cause thread pool starvation and hangs.

Steps to reproduce

This issue is intermittent and occurs on Application start-up.

Expected result

What should happen?

Actual result

The application was not accepting any other requests as the thread was blocked

Environment

Windows 64

[Shane32]

Newtonsoft.Json is a synchronous package and does not internally contain asynchronous serialization calls. So the easiest fix would be to use the System.Text.Json serializer which fully supports async reading and writing.

You said you are using 'package version 3.4' -- are you referring to GraphQL.Server.Transports.AspNetCore version 3.4 ? That specifically uses version 2.3.0 of GraphQL.NET; the latest version of GraphQL.NET is 7.2.1. I do not believe the server project contains a compatible System.Text.Json serializer to use with that version.

While of course I'd suggest moving to the latest version, even moving up one major version to GraphQL 3.x (with Server 4.x), you can utilize the System.Text.Json serializer.

Note that the current version of GraphQL.NET with GraphQL.NET Server (7.2.1 and 7.2.0 respectively) supports hosting on top of either (a) ASP.NET Core 2.1, or (b) ASP.NET Core 3.1 through 7.0, for maximum compatibility. For ASP.NET Core 2.1, you may run on top of either .NET Framework or .NET Core 2.1.

Migration notes for each new major version of GraphQL.NET are listed here:

• https://graphql-dotnet.github.io/docs/migrations/migration3
• https://graphql-dotnet.github.io/docs/migrations/migration4
• https://graphql-dotnet.github.io/docs/migrations/migration5
• https://graphql-dotnet.github.io/docs/migrations/migration7

We only have migration notes for the server project between version 6 and version 7:

• https://github.com/graphql-dotnet/server/blob/master/docs/migration/migration7.md

Note that the current version of GraphQL.NET does support the Newtonsoft.Json converter and it does still contain an HttpResponseStreamWriter which might still contain the bug you mentioned. But any fix would be applied to current versions of GraphQL.NET, so I'm not sure I can be of much help at the moment. So I recommend switching to a version of GraphQL.NET where you can use the asynchronous System.Text.Json serializer.

[csrivaab-jci]

Yes, I am using the graphql.server.transports.aspnetcore 3.4.0, thanks a lot for your valuable suggestions. if GraphQL.NET is still using the Newtonsoft.Json, so probably the issue would still be there as you mentioned, but I will upgrade to latest version of package.

If I face this issue again with the latest version what would be your suggestion?

@Shane32

[Shane32]

Let's cross that bridge when we come to it. Again, I'd strongly recommend switching to the System.Text.Json serializer, so unless you have a particular need for Newtonsoft.Json, I would switch to using that regardless.

[Shane32]

Note that this PR contains a potential fix for the issue you mentioned:

• Use buffer streams to solve the problem with synchronous reads. server#733

It would need to be revised for v7

[Shane32]

graphql.server.transports.aspnetcore 3.4.0,

We are currently on version 7.x. If you experience the issue on a current version, we may be able to help further.

[csrivaab-jci]

After upgrading to the latest package, we no longer encountered this issue. Thank you @Shane32 for guiding us.