New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deadlock on ConcurrentRequestQueue.WaitForBelowRequestLimit() #3414
Comments
Hi! Thanks for opening your first issue here! Please make sure to follow the issue template - so we could help you better! |
You are completely right. For some reason I thought the But I can see that Very embarrassing. I have created PR #3415 |
Another edge case, try set Seems the count should be decrease before Wait , and increase again after Wait to avoid that. And all compare to
BTW: |
You are completely right. It should perform decrement / increment when getting into the throttle state. This will allow correct behavior when very low RequestLimit.
The -1 parameter only works for the DequeueBatch that returns an array.
|
@yyjdelete Updated #3416 to include Thanks again., |
fixed by #3415 |
@yyjdelete NLog 4.6.4 has been released: https://www.nuget.org/packages/NLog/4.6.4 |
Hi! Thanks for reporting this feature/bug/question!
Please keep / fill in the relevant info from this template so that we can help you as best as possible.
QUESTIONS are preferred on StackOverflow. You could expect a faster response there (but do include all the info below). Use the tag "nlog" https://stackoverflow.com/questions/ask
For .NET Core users, please check the platform support: https://github.com/NLog/NLog/wiki/platform-support
NLog version: 4.6.3
Platform: .Net 4.7.2/ .NET Core 2
Current NLog config (xml or C#, if relevant)
It happen when set
<default-wrapper xsi:type="AsyncWrapper" overflowAction="Block" forceLockingQueue="false" />
(or netcore2.0 withoutforceLockingQueue
). And can be reproducted with the below code.You can see some threads are block on line133(
Monitor.Enter(_logEventInfoQueue);
), but the queue is empty at that time. SeemsMonitor.Wait()
should not change the value oflockTaken
at line141.NLog/src/NLog/Targets/Wrappers/ConcurrentRequestQueue.cs
Lines 118 to 160 in 610f368
Still block even if the queue is empty at that time.
No block after the queue be empty.
The text was updated successfully, but these errors were encountered: