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

Switch to blocking mutex lock #231

Merged
merged 2 commits into from
Nov 28, 2018
Merged

Conversation

apezel
Copy link

@apezel apezel commented Nov 27, 2018

Switch to a blocking mutex lock to prevent "Unable to ge transport" error in multi threaded applications.
references issue #230

Switch to a blocking mutex lock to prevent "Unable to ge transport" error in multi threaded applications.
referenced issue AlexPikalov#230
@AlexPikalov
Copy link
Owner

This solution seems to be reasonable but I'd like to investigate how it behaves during executing a large number of parallel request. Just don't want to bump into a panic.

Could you please provide some info about how many simultaneous threads did you have and how many nodes?

BTW Some time ago I was thinking about providing a very specific load balancer strategy which would always return the same single transport (node). I think a cluster consisting of a single node might be a quite common case so any calculations might be omitted for such a simple case.

If it's sort of your case and/or you are interested in that feel free to create an issue for implementation of such strategy and eventually submit a PR.

@AlexPikalov
Copy link
Owner

Please give me an another day to play around this solution and we'll merge it.

Thanks for your PR

Add a "no load balancing" strategy for clusters of 1 node
@apezel
Copy link
Author

apezel commented Nov 28, 2018

Do you mean something like this ?

@AlexPikalov
Copy link
Owner

AlexPikalov commented Nov 28, 2018

Exactly 👍 Thank you

As for the solution with lock instead of try_lock it's okay since lock panics if

This function might panic when called if the lock is already held by the current thread.

which seems to be non-achievable because method next contains only one lock and a lock is released immediately after next execution finishes

Copy link
Owner

@AlexPikalov AlexPikalov left a comment

Choose a reason for hiding this comment

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

Thank you for your PR

@AlexPikalov AlexPikalov merged commit 233212b into AlexPikalov:master Nov 28, 2018
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.

2 participants