-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
Error log full of ServerErrorHandler: Poco::Exception. Code: 1000, e.code() = 107, Net Exception: Socket is not connected #34218
Comments
Check what the thread was doing before and after the exception. |
So, what is the status ? I'm facing the same problem |
We always have an error after inserting data, but not on every request
|
We have too.
How to solve this? |
Also seeing the same after upgrading to 24.4.0: |
This is a mistake. We don't support alternative, third-party builds. Read https://clickhouse.com/docs/knowledgebase/difference_between_official_builds_and_3rd_party |
@alexey-milovidov other reports in the issue are for the official build though. We also experience it on official builds. Don’t close because 1 commenter uses a third-party version… |
Confirming the same problem on vanilla Sentry 24.5.1 |
Anyone has a solution to this ? I'm facing the same issue on vanilla Sentry 24.5.1 |
@mbovingfred @csvan Do you experience related issues at a client side? Or is it only about spoiled logs? |
None
Yes exactly |
Same as above ^ |
I get the error when i check clickhouse container logs |
FYI error persists on Sentry 24.6.0
|
The error is reported when a user immediately disconnects with TCP RST after connecting. |
Yes, no one really minds that it’s happening. The problem is that it makes logs entirely unusable. It indicates problems with ClickHouse loudly polluting the logs for what any other system uses a debug-level « connection reset by peer » log line. It is in fact completely inappropriate to throw error-level logs with stacktraces in the logs for it… Closing this issue is very wrong. |
Yes kindly do not close this, at the very least the log level should be downgraded |
We are experiencing this log spam as well in a production environment.
It is reasonable to believe there will be a degree of unreliability over a network, especially under high load. In our case, we do not observe any negative effect correlated with this debug message (besides spamming our logs). |
So what exactly do we need to do? |
Moving this error to TRACE level (or whatever is the lowest developer-intended log level) seems appropriate to me. If a client sends a TCP RST, which is a very appropriate way for an HTTP client to terminate a non-H2-multiplexed HTTP connection, it should not appear at the standard log level, especially not with an entire stacktrace. You could argue that it’s already a debug-level log but the CH team has repeatedly indicated that users are expected to run it at debug log level rather than information level, so it is de-facto what would be considered « info » level in other software. |
We run all our servers with the Trace level by default. |
That's great, then you can move this to trace, still see it yourself, and anyone else who doesn't do so won't see it anymore...? Win-win |
Yes, this makes sense. |
While I'm happy to make this change, it seems that there's already a PR related to it here #67177 Any preference between my proposal (move it to TRACE) and that PR (keeping it at DEBUG, but ratelimiting it)? |
Rate-limiting is better. |
Currently it's |
I've got the error log full of errors like this
The text was updated successfully, but these errors were encountered: