-
Notifications
You must be signed in to change notification settings - Fork 914
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
[BUG] Data race when trying to use keep alive that re-login #3571
Comments
Howdy 🖐 prziborowski ! Thank you for your interest in this project. We value your feedback and will respond soon. If you want to contribute to this project, please make yourself familiar with the |
Thanks for the test case and details. Ideally clients would only have 1 thread attempting Login at a time. But we can also just put a sync.Mutex around |
dougm
added a commit
to dougm/govmomi
that referenced
this issue
Oct 5, 2024
dougm
added a commit
to dougm/govmomi
that referenced
this issue
Oct 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I am seeing that if I try to perform a Login, that it will modify the userSession object.
And if I'm also calling something like UserSession(), or maybe SessionIsActive, it is reading the object.
I'm not sure if I should be adding locks on the client code or not.
https://github.com/vmware-tanzu/vm-operator/blob/main/pkg/providers/vsphere/client/client_test.go#L305,L356 is a somewhat contrived case of the race.
To Reproduce
I wrote a small test-case that just loops forever (obviously not a candidate for checking in if it no longer hits the data race):
Expected behavior
Either hoping that it doesn't race here, or possibly suggestion on what locking structure to add from client.
Affected version
commit 3db76c0
Screenshots/Debug Output
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: