Skip to content
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

Is hyper::client::connect::http: connected to 172.19.0.5:4566 debug level log? #14539

Closed
lmatz opened this issue Jan 12, 2024 · 9 comments · Fixed by #16396
Closed

Is hyper::client::connect::http: connected to 172.19.0.5:4566 debug level log? #14539

lmatz opened this issue Jan 12, 2024 · 9 comments · Fixed by #16396
Milestone

Comments

@lmatz
Copy link
Contributor

lmatz commented Jan 12, 2024

SCR-20240112-oz1

This log seems to generate forever in a very frequent way

@github-actions github-actions bot added this to the release-1.7 milestone Jan 12, 2024
@lmatz lmatz changed the title Is DEBUG rw-streaming actor{otel.name="Actor 92" actor_id=92 prev_epoch=5755251724189696 curr_epoch=5755251730939904}:executor{otel.name="Project 5C00000002 (actor 92)" actor_id=92}:executor{otel.name="RowIdGen 5C00000001 (actor 92)" actor_id=92}:executor{otel.name="Source 5C000027B1 (actor 92)" actor_id=92}:source_parser{actor_id=92 source_id=1001}: hyper::client::connect::http: connected to 172.19.0.5:4566 debug level log? Is hyper::client::connect::http: connected to 172.19.0.5:4566 debug level log? Jan 12, 2024
@BugenZhao
Copy link
Member

Originated from #14227 😄

@lmatz
Copy link
Contributor Author

lmatz commented Jan 15, 2024

True, I thought this gets printed only at the very first connection 😬, but from the log (another few pages), it seems it will periodically be printed.

Maybe let it be there for now as normally the log level is set to info.

@lmatz lmatz closed this as not planned Won't fix, can't repro, duplicate, stale Mar 6, 2024
@hzxa21
Copy link
Collaborator

hzxa21 commented Mar 15, 2024

This log entry seems to be flooding in the logs for CNs and it is rarely used during troubleshooting. Should we avoid this log?

@MrCroxx
Copy link
Contributor

MrCroxx commented Mar 15, 2024

Is it still helpful when there is DNS issue? If not, I'll remove it. Otherwise, I'll add a config to switch it.

@hzxa21
Copy link
Collaborator

hzxa21 commented Mar 15, 2024

Is it still helpful when there is DNS issue? If not, I'll remove it. Otherwise, I'll add a config to switch it.

I don't have a context for the previous DNS issue? Is it DNS issue inside RW cluster or between RW and user?

@MrCroxx
Copy link
Contributor

MrCroxx commented Mar 18, 2024

Is it still helpful when there is DNS issue? If not, I'll remove it. Otherwise, I'll add a config to switch it.

I don't have a context for the previous DNS issue? Is it DNS issue inside RW cluster or between RW and user?

@lmatz has used the log as evidence to show the user that some connection error is caused by its DNS, not RW.

@lmatz
Copy link
Contributor Author

lmatz commented Mar 18, 2024

yes, a really rare case I suppose, it was added per the user's request. I think it's fine to remove it now if it is annoying. No complaints about the incident after that

@BugenZhao
Copy link
Member

We can still enable it by setting the RUST_LOG env var without making it enabled by default.

@fuyufjh
Copy link
Member

fuyufjh commented Apr 4, 2024

+1 for removing it. Really disturbing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants