-
-
Notifications
You must be signed in to change notification settings - Fork 246
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: DB connection locks up under load calling DB.Create(), regression in 6.1.0 vs 6.0.8 #800
Comments
Hi @saurori, I have some questions about the reproduction conditions, the main questions are:
I would like to use this issue as a tracking issue for this issue in pop, and gobuffalo/buffalo-pop#28 as the tracking issue for the buffalo-pop if it needed. There are some related issues, so please let me update your OP to include the list of the issues and related issues/PRs. |
This issue may be different than the ones I linked. I tested this very precisely against Tested (use
|
Ah! I see. Thanks for the kind sharing the information! |
Confirmed. The first table is the result of the test for #28, which used
As we already knew, there was an issue when we use This symptom of the issue can be explained as a deadlock:
The second table is for this issue, which used
Interestingly, no-mw + no-tx case also has the same symptom. The main difference between v6.0.8 and v6.1.0 is the logging. I added transaction/connection information on the log line to track them with requests. Anyway, long story short, I found that this issue happened by this line: v6.0.8...v6.1.0#diff-006ceb789dde7f1890eaf42061a363160cb61de6dc6495277349cfe99bd8343cR84 When the logging function was called with store value, it seems like there are some dark magic behind the scene. If I revert this to the old function, the symptom will disappear. (In case of the ID is UUID) However, I don't want to write a quick patch for this because I was preparing another change to the logging stuff and the version will change this behavior (copying store) too. Please use v6.0.8 if you have this issue! |
Hi @saurori, I think I reproduced the issue you faced. Do you think I saw the same issue you described? If so, I found the root cause but I still don't know what magic happened with sqlx's connection pool management. I guess some of Pop's usage is not desirable but did not dig more. I would like to continue working on another change for logging which could cover this issue too. |
Hi @saurori, Could you please test with this branch? I was OK with this branch but I would like to get your confirmation. https://github.com/gobuffalo/pop/tree/pass-connection-instead-of-store |
@sio4 Thanks for digging into this. Here's what I found (let me know if you need me to test any other scenarios): To confirm I am testing the right version: go get github.com/gobuffalo/pop/v6@pass-connection-instead-of-store
go: downloading github.com/gobuffalo/pop/v6 v6.1.1-0.20221211163013-6f4136878a9c
go: upgraded github.com/gobuffalo/pop/v6 v6.1.0 => v6.1.1-0.20221211163013-6f4136878a9c
|
OMG! I found the root cause. Even though I am preparing PR #801 to improve the logging behavior, I need to understand what happened with this version so we can prevent the issue happen again. I tested more and tracked the connection information from the underlying v6.0.8...v6.1.0#diff-ff87b7c4777a35588053a509583d66c9f404ccbea9e1c71d2a5f224d7ad1323eR69 Anyway, I will work on the PR and will fix it in the next version soon. |
Description
Description
When using the DB connection directly (models.DB in a buffalo application), and calling
.Create(model)
, if the number of concurrent requests exceeds the pool size, the application will lock up and not respond to further requests. This does not happen when using thetx
transaction.This issue is only present in version
6.1.0
and not in6.0.8
.This is likely related to this issue: #364
Expected Behavior
The handler saves the model to the DB and returns.
Actual Behavior
The application locks up and does not accept any more requests.
To Reproduce
.All()
, create a model using.Create()
Related issues:
Additional Context
Details
The text was updated successfully, but these errors were encountered: