-
Notifications
You must be signed in to change notification settings - Fork 68
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
TCP Client not properly disposing of connection #112
Comments
We are also experiencing this issue when using the library with version 3.1.1 and .Net framework. If the connection for some reason is closed down, the library will not manage to reconnect. Initially, one of these errors appear in the self-log:
or
It then starts logging these exceptions:
And no logs are sent to Graylog. It would be great if the library was able to reconnect and also would retry sending the log that was being sent when the exception was thrown. Looked briefly in the code, and seems that there was a recent change that tries to reuse the TcpClient (9e99541#diff-8e1abe872c46b6cae1e6bbbe1d75740d57568e0af85b353602c7157f5522a5e0), but as I understand it a TcpClient is not designed to be reused. So that might be a possible cause of the issue. Full stack traces below:
|
Hello,
Issue:
It appears that there is a bug in v3.0+ where the TCP client does not correctly dispose of its connection. This results in the background thread crashing silently as it tries to bind to an already bound port.
Details:
We have a site set up using IIS, and after ~20-30 minutes of inactivity (no requests/logs/etc) all logging stops due to the Graylog sink trying to reconnect on a TCP port that was already bound on the initial startup. This exception was silent and did not even show in the Windows Event Viewer, nor was it causing the application to stop functioning, however all logging (all Serilog sinks) stopped working. It would seem as if this was a detached background thread, but I'm not entirely familiar with how Serilog handles its providers/sinks. I have attached some information below, we had to use
DebugDiag
to catch the exception.The offending line appears to be line 65 in the
TcpTransportClient
class:serilog-sinks-graylog/src/Serilog.Sinks.Graylog.Core/Transport/Tcp/TcpTransportClient.cs
Line 65 in 64532fa
Workaround:
There are a couple "workarounds" for these but these do not actually fix the core issue:
Sink config:
App pool config:
The text was updated successfully, but these errors were encountered: