You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After I make a RPC call via remoting and a timeout exception is thrown, when I log the exception using Log.Error, I get stuck in a deadlock.
Steps to recreate
Set up Serilog with non buffered sumo logic sink
Make an RPC call with remoting; this call throws an exception leading to a timeout exception
Log the exception with Log.Error
Current behavior
After I noticed the above, I wrapped the Log.Error in a Task.Factory.StartNew which fixed the deadlock issue. I also tried using the buffered sink with a max messages of 5, this also did not deadlock.
I took the liberty of looking at the code because we've had something similar in our own code a little while ago and I saw that you're using GetAwaiter().GetResult() to make an async task synchronous. This article makes a case of why this is a bad idea and provides a helper class to do this in a safer way.
I realise this is not really an actionable issue because it's terribly hard to reproduce without having our code, but I thought that that article and the AsyncUtil helper class might be of help to you.
Expected behavior
Not deadlock
The text was updated successfully, but these errors were encountered:
#89 resolves this issue by using ConfigureAwait(false) when doing async operations (Allowing the continuation to complete on different synchronization context).
Installed product versions
Description
After I make a RPC call via remoting and a timeout exception is thrown, when I log the exception using Log.Error, I get stuck in a deadlock.
Steps to recreate
Current behavior
After I noticed the above, I wrapped the Log.Error in a Task.Factory.StartNew which fixed the deadlock issue. I also tried using the buffered sink with a max messages of 5, this also did not deadlock.
I took the liberty of looking at the code because we've had something similar in our own code a little while ago and I saw that you're using GetAwaiter().GetResult() to make an async task synchronous.
This article makes a case of why this is a bad idea and provides a helper class to do this in a safer way.
I realise this is not really an actionable issue because it's terribly hard to reproduce without having our code, but I thought that that article and the AsyncUtil helper class might be of help to you.
Expected behavior
Not deadlock
The text was updated successfully, but these errors were encountered: