[fix][metadata] Fix allow updating the released resource lock value.
Motivation
In the current implementation, If the lock was expired by release or revalidate, the expireFuture will invoke to notify the user to clean up.
However, we can still update the lock value, even if the lock is already expired.
Modifications
- Disallow update lock value if the resource lock is already released.
- Introduce
Revalidatingstate to avoid invokingrevalidateandupdateValueconcurrently.
Verifying this change
- [x] Make sure that the change passes the CI checks.
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)
- Added integration tests for end-to-end deployment with large payloads (10MB)
- Extended integration test for recovery after broker failure
Does this pull request potentially affect one of the following parts:
If the box was checked, please highlight the changes
- [ ] Dependencies (add or upgrade a dependency)
- [ ] The public API
- [ ] The schema
- [ ] The default values of configurations
- [ ] The binary protocol
- [ ] The REST endpoints
- [ ] The admin CLI options
- [ ] Anything that affects deployment
Documentation
-
[ ]
doc-required(Your PR needs to update docs and you will update later) -
[x]
doc-not-needed(Please explain why) -
[ ]
doc(Your PR contains doc changes) -
[ ]
doc-complete(Docs have been already added)
Matching PR in forked repository
PR in forked repository: https://github.com/mattisonchao/pulsar/pull/4
@mattisonchao - thank you for your work on the lock implementation. I have been having issues related to locks recently. Here is an issue describing my observations and some potential solutions. https://github.com/apache/pulsar/issues/17759
The pr had no activity for 30 days, mark with Stale label.