Shulou(Shulou.com)06/03 Report--

This article will explain in detail how to solve the problem of EnyimMemcached deadlock caused by GetHostAddressesAsync in .NET Core. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

The biggest obstacle we have encountered so far in moving our site from ASP.NET + Windows to ASP.NET Core + Linux is that there is no available memcached client that supports .NET Core.

We have been using EnyimMemcached, and without any other choice, we tried to migrate EnyimMemcached to the .NET Core. Based on the .NET Core, the code has been modified and passed the test in the development environment. It is normal to access the Linux server by yourself (no concurrent visits), but as long as you access a certain amount of access, there will be a deadlock and the browser request will be jammed.

This problem has been bothering us for a long time, and it was only yesterday that it occurred when the memcached server name was resolved to an IP address.

Var addresses = System.Net.Dns.GetHostAddressesAsync (host) .Result

This is the code we modified when we migrated EnyimMemcached to .NET Core, and the synchronization method was called before:

Var addresses = System.Net.Dns.GetHostEntry (host)

Since there are no synchronous methods in the System.Net.Dns of the .NET Core Framework, only asynchronous methods, we can only call asynchronous methods in this way.

When you see the code above, you may be surprised: how to use .Result, why not use await? No wonder there is no deadlock.

Your surprise is absolutely right. We are also well aware of the harm of .Result and firmly do not use it in our usual code. However, when modifying the EnyimMemcached code at that time, because this method was called in the constructor of MemcachedClient, it could not be changed to await call, so I was forced to use .Result, and then forgot about the changes in this place. I just found out yesterday that the culprit is very likely to be .Result here, so I took this as a breakthrough to do everything I could to call an asynchronous method in a synchronous method, and ask for support in the blog-- how to avoid deadlock when calling an asynchronous method in a synchronous method.

As a result, all the methods that can be thought of to call asynchronous methods with synchronous methods that can be found fail to solve the deadlock problem. If we really can't find a solution, we're going to use the last and ugliest trick-- instead of Dns.GetHostAddressesAsync (), use ProcessStartInfo to invoke command-line commands to parse IP, such as using the getent hosts hostname on Linux.

Before I was ready to give up, today I thought about what other clues might have been left out. It suddenly occurred to me that I forgot to look at the source code implementation of Dns.GetHostAddressesAsync (). Although there is not much hope, it is just an asynchronous method, but we still need to take a look.

So check out the corefx source code from github, open the Dns.GetHostAddressesAsync () source code, it feels a little strange, how to use Task.Factory.FromAsync ()?

Public static Task GetHostAddressesAsync (string hostNameOrAddress) {NameResolutionPal.EnsureSocketsAreInitialized (); return Task.Factory.FromAsync ((arg, requestCallback, stateObject) = > BeginGetHostAddresses (arg, requestCallback, stateObject), asyncResult = > EndGetHostAddresses (asyncResult), hostNameOrAddress, null;}

At first, I didn't react to it. I just posted this code in the supplementary question asked by the blog. After posting it, I suddenly came back. Hey, why is there no async keyword? The last name of the method is Async, which we always thought was the async method and had no doubt at all.

There is no async, but the return parameter is of type Task, so it is no problem to call in the synchronous method, as long as the .wait () method is called before accessing .Result, so change to the following code:

Task task = System.Net.Dns.GetHostAddressesAsync (host); task.Wait (); var addresses = task.Result

The deadlock problem is solved immediately!

The name of the method ends with Async, but it is not an async method. The impression at that time is that your eyes betray your heart. If it is not my own misunderstanding (as long as it ends with Async, it should be the async method), it is a kind of rogue behavior, like the rogue of HttpClient-- implements the IDispose interface but does not really Dispose.

In any case, the biggest obstacle to our migration to .NET Core has finally been removed, and it's worth celebrating!

The EnyimMemcached code that supports the .NET Core still needs some modification and refinement, and when the modification is done, we will release the source code and the NuGet package.

This is the end of this article on "how to solve the EnyimMemcached deadlock problem caused by GetHostAddressesAsync in .NET Core". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.