-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Thread blocked when using one global instance of ClientResources but repeatedly opening and closing connections #2879
Labels
type: bug
A general bug
Milestone
Comments
Possibly related to #1429 |
Closed
4 tasks
tishun
pushed a commit
that referenced
this issue
Sep 13, 2024
tishun
pushed a commit
to tishun/lettuce-core
that referenced
this issue
Nov 1, 2024
…is#2961) * fix:deadlock when reentrant exclusive lock redis#2905 * confirm won't blocking other thread * apply suggestions
tishun
added a commit
that referenced
this issue
Nov 1, 2024
thachlp
pushed a commit
to thachlp/lettuce
that referenced
this issue
Dec 31, 2024
…is#2961) * fix:deadlock when reentrant exclusive lock redis#2905 * confirm won't blocking other thread * apply suggestions
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
Thread blocked when using one global instance of ClientResources but repeatedly opening and closing connections.
Similar issues I had found about using multiple clientResources over here #1269.
However we only used one global ClientResources and still faced a similar looking error.
Current Behavior
Following the guidelines of lettuce, we only used one instance of ClientResources in a single JVM.
Created multiple RedisClusterClient in one JVM.
As connection.reset is said to cause bugs and deprecated, we seek to emulate a reset type of behaviour by closing the connection when we hit an exception and opening a brand new one.
We thought doing it like this would work.
Then repeatedly connect and closeAsync(when we hit some exception).
Eventually threads will be blocked, refer to the exception below under stack trace.
After the lock is engaged, we can no longer unlock it.
Stack trace
Expected behavior/code
Expected it not to be blocked
Environment
Additional context
None
The text was updated successfully, but these errors were encountered: