-
Notifications
You must be signed in to change notification settings - Fork 895
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
Fix the PendingAddOp is not recycled when LedgerHandler closed #3321
Conversation
--- **Motivation** When adding an entry into a bookie, the entry data lifecycle is handled by the bookie client. The data buffer will be released after receiving a corresponding response from the bookie server. So the user doesn't care about the entry buffer releasing. But when the ledgerHandler is closed, the PendingAddOp is not recycled which leads to the data buffer never being released. We should release that after the callback executed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change makes sense to me.
I am not sure we buy much advantage by recycling the Op object in this corner case.
I am afraid of possible side-effects that we would find only in the future.
btw +1 from me, good catch !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice catch.
I have encountered the problem of too many PendingAddOp objects causing GC in pulsar, this may solve my problem.
--- **Motivation** When adding an entry into a bookie, the entry data lifecycle is handled by the bookie client. The data buffer will be released after receiving a corresponding response from the bookie server. So the user doesn't care about the entry buffer releasing. But when the ledgerHandler is closed, the PendingAddOp is not recycled which leads to the data buffer never being released. We should release that after the callback executed. (cherry picked from commit 3d01e6e)
I have cherry-picked this change to branch-4.15 and branch-4.14 |
--- **Motivation** When adding an entry into a bookie, the entry data lifecycle is handled by the bookie client. The data buffer will be released after receiving a corresponding response from the bookie server. So the user doesn't care about the entry buffer releasing. But when the ledgerHandler is closed, the PendingAddOp is not recycled which leads to the data buffer never being released. We should release that after the callback executed. (cherry picked from commit 3d01e6e)
…e#3321) --- **Motivation** When adding an entry into a bookie, the entry data lifecycle is handled by the bookie client. The data buffer will be released after receiving a corresponding response from the bookie server. So the user doesn't care about the entry buffer releasing. But when the ledgerHandler is closed, the PendingAddOp is not recycled which leads to the data buffer never being released. We should release that after the callback executed. (cherry picked from commit 3d01e6e)
…e#3321) --- **Motivation** When adding an entry into a bookie, the entry data lifecycle is handled by the bookie client. The data buffer will be released after receiving a corresponding response from the bookie server. So the user doesn't care about the entry buffer releasing. But when the ledgerHandler is closed, the PendingAddOp is not recycled which leads to the data buffer never being released. We should release that after the callback executed. (cherry picked from commit 3d01e6e)
…gerHandleAdv (#3621) Descriptions of the changes in this PR: Apply recycle logic during add entry creation but ledger close to LedgerHandleAdv ### Motivation This pr is a supplement to #3321 If I understand correctly. these recycled logic should be applied to LedgerHandleAdv (cherry picked from commit 0d2fbe4)
…gerHandleAdv (apache#3621) Descriptions of the changes in this PR: Apply recycle logic during add entry creation but ledger close to LedgerHandleAdv ### Motivation This pr is a supplement to apache#3321 If I understand correctly. these recycled logic should be applied to LedgerHandleAdv (cherry picked from commit 0d2fbe4) (cherry picked from commit b4d0be2)
…gerHandleAdv (apache#3621) Descriptions of the changes in this PR: Apply recycle logic during add entry creation but ledger close to LedgerHandleAdv ### Motivation This pr is a supplement to apache#3321 If I understand correctly. these recycled logic should be applied to LedgerHandleAdv
…gerHandleAdv (#3621) Descriptions of the changes in this PR: Apply recycle logic during add entry creation but ledger close to LedgerHandleAdv ### Motivation This pr is a supplement to #3321 If I understand correctly. these recycled logic should be applied to LedgerHandleAdv (cherry picked from commit 0d2fbe4)
…e#3321) --- **Motivation** When adding an entry into a bookie, the entry data lifecycle is handled by the bookie client. The data buffer will be released after receiving a corresponding response from the bookie server. So the user doesn't care about the entry buffer releasing. But when the ledgerHandler is closed, the PendingAddOp is not recycled which leads to the data buffer never being released. We should release that after the callback executed.
…gerHandleAdv (apache#3621) Descriptions of the changes in this PR: Apply recycle logic during add entry creation but ledger close to LedgerHandleAdv ### Motivation This pr is a supplement to apache#3321 If I understand correctly. these recycled logic should be applied to LedgerHandleAdv
Motivation
When adding an entry into a bookie, the entry data lifecycle
is handled by the bookie client. The data buffer will be
released after receiving a corresponding response from the
bookie server. So the user doesn't care about the entry
buffer releasing.
But when the ledgerHandler is closed, the PendingAddOp is not
recycled which leads to the data buffer never being released.
We should release that after the callback is executed.