[Bug] StackEchange.Redis 2.7.* version not working with Multiple Thread.

[dgorsawala]

The thread '[Thread Destroyed]' (0x735c) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0xf2b8) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0x114ec) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0x100a4) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0xea7c) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0xbfd0) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0xba90) has exited with code 0 (0x0). Exception thrown: 'System.TypeLoadException' in Microsoft.AspNetCore.Server.Kestrel.Core.dll Exception thrown: 'System.TimeoutException' in ProviderESN.dll Exception thrown: 'System.TimeoutException' in mscorlib.dll Exception thrown: 'Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException' in Microsoft.VisualStudio.TestPlatform.TestFramework.dll Exception thrown: 'Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException' in mscorlib.dll The thread '[Thread Destroyed]' (0xb7f0) has exited with code 0 (0x0). Exception thrown: 'System.Threading.ThreadAbortException' in mscorlib.dll Exception thrown: 'System.Threading.ThreadAbortException' in mscorlib.dll Exception thrown: 'System.Threading.ThreadAbortException' in Microsoft.Extensions.Logging.Console.dll Exception thrown: 'System.Threading.ThreadAbortException' in mscorlib.dll The thread '[Thread Destroyed]' (0x6a28) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0x9568) has exited with code 0 (0x0). Exception thrown: 'System.Threading.ThreadAbortException' in ShakenAPI.dll Exception thrown: 'System.Threading.ThreadAbortException' in mscorlib.dll Exception thrown: 'System.Threading.ThreadAbortException' in mscorlib.dll The thread 0x10b70 has exited with code 0 (0x0). The thread 0xb5c0 has exited with code 0 (0x0). The thread 0x8ce4 has exited with code 0 (0x0). The thread 0xf570 has exited with code 0 (0x0). The thread 0xf83c has exited with code 0 (0x0). Exception thrown: 'System.CannotUnloadAppDomainException' in mscorlib.dll Exception thrown: 'System.CannotUnloadAppDomainException' in mscorlib.dll The thread 0x77f8 has exited with code 0 (0x0). The thread 0xc280 has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0x5bb8) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0xb88c) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0x2ea8) has exited with code 0 (0x0). The thread '[Thread Destroyed]' (0xf04c) has exited with code 0 (0x0). Exception thrown: 'System.Net.Sockets.SocketException' in mscorlib.dll Exception thrown: 'System.Net.Sockets.SocketException' in mscorlib.dll The program '[49888] testhost.net48.exe: Program Trace' has exited with code 0 (0x0). The program '[49888] testhost.net48.exe' has exited with code 4294967295 (0xffffffff).

[mgravell]

Can you be more specific than "2.7.*" ? Exactly which version, and exactly which version of .NET? This looks like asp.net is involved, so: what exactly? Distributed cache? Output cache? It looks like this is a unit test all, so: what does the unit test look like? Give us something to work with here :)

[sameerjoshinice]

Hi @mgravell,

I work in the same team as Divya, the reporter of this issue.

If you see above diagram, we have unit tests project A which is .net framework 4.8. This project references project C which is also .net framework 4.8 based. Unit tests from project A are calling class methods from project C and those result into calling await client.SendAsync where client is an instance of System.Net.Http.HttpClient . Note project C has reference of System.Net.Http DLL which comes with .Net48 framework installation. This call of SendAsync results into timeout when the reference of StackExchange.Redis 2.7. means any minor version of 2.7 is added as a reference in project D. If we use 2.6. versions, it works fine. Its not clear why HttpClient timeout is the result of just adding a reference to the StackExchange.Redis 2.7. versions, while same works fine with 2.6. version.

[dgorsawala]

By mistake, it was marked as completed so I reopened it.

[mgravell]

The diagram shows .NET Framework 4.8, but the stacktrace shows "Exception thrown: 'System.TypeLoadException' in Microsoft.AspNetCore.Server.Kestrel.Core.dll" - can I double check where we're running here?

If we are on .NET Framework, then "binding redirects" are the most common cause of a TypeLoadException - probably System.Memory or System.Runtime.CompilerServices.Unsafe (see https://nickcraver.com/blog/2020/02/11/binding-redirects/). If you list exact package numbers rather than 2.6. and 2.7., we can check the dependencies of each more precisely. Note that while a library might target .NET Standard, you never run "on" .NET Standard - it always runs on a concrete runtime.

Interesting do you see what isn't in that stack-trace? StackExchange.Redis ;p

[dgorsawala]

We are using 2.7.33 StackExchange.Redis. We have a .Net Framework 4.8 project which has the AspNet.Core dependency as attached.

[mgravell]

Ultimately, the Microsoft.AspNetCore package (edit: not to be confused with ASP.NET Core, the actual thing) is deprecated and no longer maintained. This problem is probably an assembly-binding issue that can be resolved via the link I already supplied, but it is hard to see from that stack. I'm not going to propose spending time trying to get SE.Redis "current" working with Microsoft.AspNetCore 2.2.0 against .NET Framework 4.8; if the current 2.7 build doesn't work, perhaps use whatever previous one did work? Sure, you won't have any recent updates, but that's true of literally everything else that you're using. If you happen to debug that and get to the bottom of it, I'd love to hear what it is (as I say: my money is on an assembly binding redirect), but I simply can't justify time looking at that, without a very compelling reason.

Honestly, I know you're probably sick of hearing this, but my strongest advice here would be: get on .NET "current" (meaning: .NET 8 or something similar); you will find it increasingly hard to get support for this scenario. I wrote about this 4 years ago - it has only become more true with time.