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

fix: refresh connections to avoid hotspotting of load distribution #5227

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

snarkychef
Copy link
Member

@snarkychef snarkychef commented Oct 24, 2024

Description

We noticed uneven load distribution to upstream transformation services due to long lived connections. So recycling client to force refresh of connections to transformer.

Linear Ticket

https://linear.app/rudderstack/issue/PIPE-1669/refresh-transformer-connections-periodically-on-client-side

Security

  • The code changed/added as part of this pull request won't create any security issues with how the software is being used.


if r.ttl > 0 && time.Since(r.lastRefreshTime) > r.ttl {
r.client.CloseIdleConnections()
r.client = r.clientFunc()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if 1 goroutine comes and gets a http client and make a http-request and while that request is in flight another go routine comes and ttl is passed we closed all the ideal conns(conn made by the 1st goroutine is still not closed as the req is in flight) and recycle the http client. But since first req is already in flight can this cause some resource to leak?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats true. We should combine this with: IdleConnTimeout (can be equal to r.lastRefreshTime) Eventually resources would freed up.

Copy link
Member

@lvrach lvrach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add this change behind a flag.

I am bit sceptical if we should use this approach in production or look for a cleaner solution.

However, we can merge it on master behind a flag, and enable in selected cases.

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 this pull request may close these issues.

3 participants