I'm having trouble with the same phenomenon as the title says
The server is Windows Server 2012 R2
The development environment is Visual Studio 2015+ASP.NET (.NET Framework 4.6.2)
That's it
Roughly speaking
Calling the Web API using Unmanaged dll gets stuck
If you do the same thing with CGI(exe) on C, it will work.
That's it
I will write the details below, including the results of various trials.
I am creating an unmanaged dll (64bit) that uses two third-party libraries (this DLL is 1)
I made a console app in C language that links を to call functions (2)
I created the MVC Web Api2 controller to call を (3)
， and は are placed on the server and both are called through IIS
When I restarted the server and called を when I thought the service was up, it responded in a common sense time
If you try the same thing in で, you won't get a response (you will be forced to terminate due to client side timeout or application pool ping error).
This condition does not improve after waiting for about 30 minutes (I don't know because I don't wait any longer)
If you call を and then call を, they will respond in about one or two attempts
If you return a response at least once, the rest will return a response normally.
Returns even if rebooted with iisreset command, etc.
Restarting the server reverts to its original state (no response)
"When I looked at ""slow boot"" etc., <generatePublisherEvidence enabled="false"/> came out, so I tried it, but it didn't change (there was a description that it didn't matter after v4, and now I have a server connected to the Internet, but it hasn't changed)."
When I tried to output the log in each step of の, it seemed to stop around the initialization of the third-party library, but the stop was not fixed (the log is always flushed and closed, so I think it's just before it stops).
I'm at my wit's end
Could you please let me know if there are any causes or workarounds?
As someone familiar with it, we have concluded that third-party libraries are likely to be defective or environmentally sensitive.
There is no problem as long as I call it with the Native app, so I changed it to go through the Native app without calling it directly with ASP.NET
The difference between linking DLLs to call methods and calling them exe external processes is
1) Multi-threaded problems
2) Failure to open resources
I think there is a difference between
In the case of exe boot, all resources in memory are released at the end of the call.
This is a problem if you call from dll and you are not freeing up important resources within the function.
Considering this part, I felt that while processing the initialization routine for DLL calls, the following 呼び出し call occurred and deadlocked.
When invoking ode, use System.Threading.Mutex to multi-thread the processing
Why don't you add exclusive treatment so that you don't do it?
After the second time
if multi-threaded works properly
Mutex may be the first time to be exclusive.
However, if the library is not multi-threaded in the first place
Must be exclusive for each call.
Also, after using it for a long time, the applicable native application has a memory leak etc.
Has it occurred? I think we need to check it in the long run.
© 2024 OneMinuteCode. All rights reserved.