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

[client] Add peer conn init limit #3001

Merged
merged 2 commits into from
Dec 9, 2024
Merged

[client] Add peer conn init limit #3001

merged 2 commits into from
Dec 9, 2024

Conversation

mlsmaycon
Copy link
Collaborator

Describe your changes

Limit the peer connection initialization at 200 peers at the same time

Issue ticket number and link

Checklist

  • Is it a bug fix
  • Is a typo/documentation fix
  • Is a feature enhancement
  • It is a refactor
  • Created tests that fail without the change (if possible)
  • Extended the README / documentation, if necessary

Limit the peer connection initialization at 200 peers at the same time
@mlsmaycon mlsmaycon changed the title Add peer conn init limit [client] Add peer conn init limit Dec 7, 2024

// Done decrements the internal WaitGroup counter and releases a semaphore slot.
func (sg *SemaphoreGroup) Done() {
sg.waitGroup.Done()
Copy link
Contributor

Choose a reason for hiding this comment

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

If we run once time the Add() and run multiple times the Done() then it will cause an exception. If we use exported functions of this struct from multiple go routines then this part is dangerous.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

any suggestions?

Copy link
Contributor

Choose a reason for hiding this comment

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

It carries the exact same risk as using a plain sync.WaitGroup, as long as the usage guarantees 1:1 Add and Done usage it should be fine, no?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think the solution is simple. Just fully delete the sg.waitGroup. The exported Wait has been used by the unit test only, but we can do it in different way. After all Go routine exited, check the len of the channel. It is not nice way to check internal variables in unit test but the code will be simpler and less risky to use.

Copy link
Contributor

Choose a reason for hiding this comment

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

@mohamed-essam I think this is Go philosophy question. The panic can force the developer to write, thread-safe code. I think returning with an error and handling it in the upper layer is a more defensive approach in a production-ready code. If this code snipped would be placed in internal package or it is not exported then the panic is okay from my point of view.

Copy link

sonarqubecloud bot commented Dec 8, 2024

@mlsmaycon mlsmaycon merged commit 2147bf7 into main Dec 9, 2024
26 checks passed
@mlsmaycon mlsmaycon deleted the add-peer-conn-semaphore branch December 9, 2024 16:10
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