Skip to content

CURATOR-718: Refactor CuratorFramework inheritance hierarchy by composing functionalities #517

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

Conversation

kezhuw
Copy link
Member

@kezhuw kezhuw commented Dec 31, 2024

This closes #1233.

Currently, the CuratorFrameworkImpl hierarchy is neither simple nor composable.

Ideally, there should be only one instance of CuratorFrameworkImpl. Additional functionalities should be added by intercepting methods on purpose, but not by cloning through CuratorFrameworkImpl(CuratorFrameworkImpl parent).

We could take CURATOR-626 and CURATOR-710 as lessons to know how brittle the currently hierarchy.

@kezhuw kezhuw force-pushed the CURATOR-718-refactor-CuratorFramework-inheritance-hierarchy branch from ff34371 to c2195e1 Compare December 31, 2024 05:19
@kezhuw
Copy link
Member Author

kezhuw commented Dec 31, 2024

I leave CURATOR-710 to #508.

To resolve CURATOR-710, I think we need to decide whether CuratorFramework::usingNamespace should inherit functionalities of this ? If it is yes, then we probably could fix CURATOR-710 in a straightfoward way (comparing to trick fix in #508).

@kezhuw kezhuw force-pushed the CURATOR-718-refactor-CuratorFramework-inheritance-hierarchy branch from c2195e1 to 3ecccc6 Compare December 31, 2024 05:25
Copy link
Member Author

@kezhuw kezhuw left a comment

Choose a reason for hiding this comment

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

This is a huge pr. But most changes are migrating references from CuratorFrameworkImpl to InternalCuratorFramework so we can customize functionalities by overriding methods in InternalCuratorFramework but not CuratorFrameworkImpl. Now, there will be only one CuratorFrameworkImpl per curator client.

*
* <p>An instance of {@link CuratorFramework} MUST BE an instance of {@link InternalCuratorFramework}.
*/
public abstract class InternalCuratorFramework implements CuratorFramework {
Copy link
Member Author

Choose a reason for hiding this comment

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

This is the most notable change.

NamespaceFacade and WatcherRemovalFacade are now subclasses of DelegatingCuratorFramework and InternalCuratorFramework but not CuratorFrameworkImpl.

@@ -98,15 +97,13 @@ public void flappingTest() throws Exception {
} finally {
try {
leaderSelector1.close();
} catch (IllegalStateException e) {
fail(e.getMessage());
Copy link
Member Author

Choose a reason for hiding this comment

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

@tisonkun
Copy link
Member

@kezhuw would you consider this is a release blocker? I may expect to call a release by the end of Feb. and now try to collaborate to converge the ongoing PRs.

@kezhuw
Copy link
Member Author

kezhuw commented Jan 16, 2025

would you consider this is a release blocker?

No. It is not even a bug.

@kezhuw kezhuw force-pushed the CURATOR-718-refactor-CuratorFramework-inheritance-hierarchy branch 2 times, most recently from 288799c to 2cb13cf Compare January 20, 2025 02:50
…sing functionalities

Currently, the `CuratorFrameworkImpl` hierarchy is neither simple nor
composable.

Ideally, there should be only one instance of `CuratorFrameworkImpl`.
Additional functionalities should be added by intercepting methods on
purpose, but not by cloning through `CuratorFrameworkImpl(CuratorFrameworkImpl parent)`.

We could take CURATOR-626 and CURATOR-710 as lessons to know how brittle
the currently hierarchy.
@kezhuw kezhuw force-pushed the CURATOR-718-refactor-CuratorFramework-inheritance-hierarchy branch from 2cb13cf to c47cc6f Compare January 20, 2025 04:25
}

@Override
public <DATA_TYPE> void processBackgroundOperation(
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
public <DATA_TYPE> void processBackgroundOperation(
<DATA_TYPE> void processBackgroundOperation(

.. and may need a re-format

*
* <p>An instance of {@link CuratorFramework} MUST BE an instance of {@link InternalCuratorFramework}.
*/
public abstract class InternalCuratorFramework implements CuratorFramework {
Copy link
Member

Choose a reason for hiding this comment

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

Personally, I'd prefer to name it CuratorFrameworkBase since it's used outside (as method parameter) rather than internal.

Copy link
Member Author

Choose a reason for hiding this comment

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

Renamed.

By internal, I mean it should not be used outside of curator. Currently, only impls/details packages use it. Add it is public for private usages for caution.

import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.server.quorum.flexible.QuorumVerifier;

public class DelegatingCuratorFramework extends InternalCuratorFramework {
Copy link
Member

Choose a reason for hiding this comment

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

Add some class comment for its purpose?

Also this seems another abstract class rather than an instantiable one. And we don't need impl start and close in such a bias.

Copy link
Member Author

Choose a reason for hiding this comment

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

DelegatingCuratorFramework is now abstract and start/close has been moved to subclasses.

Comment on lines 46 to 54
@Override
public void start() {
throw new UnsupportedOperationException();
}

@Override
public void close() {
throw new UnsupportedOperationException();
}
Copy link
Member

Choose a reason for hiding this comment

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

Or somewhat delegate to client.start/close also?

Copy link
Member Author

Choose a reason for hiding this comment

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

Currently, only CuratorFrameworkImpl::start/CuratorFrameworkImpl::close take effects, start/close in other facades throw. I think we should keep this behavior unchanged in an refactor.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah I noticed that this is the original manner. Then it's fine. (Although I think it's by accident, cc @Randgalt do you remember the reason why we don't delegate here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, I don't think NamespaceFacade::close should close curator.

import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.server.quorum.flexible.QuorumVerifier;

public class DelegatingCuratorFramework extends InternalCuratorFramework {
Copy link
Member

Choose a reason for hiding this comment

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

Also can be package private.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

Copy link
Member

@tisonkun tisonkun left a comment

Choose a reason for hiding this comment

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

Rest generally looks good to me.

…y composing functionalities

Notable changes to last review:
1. Rename `InternalCuratorFramework` to `CuratorFrameworkBase`.
2. Make `DelegatingCuratorFramework` `abstract` and package `private`.
3. Move `start`/`close` from `DelegatingCuratorFramework` to subclasses.
@kezhuw
Copy link
Member Author

kezhuw commented Feb 7, 2025

@tisonkun Sorry for being so late! I have pushed a fixup commit to solve the review comments.

@tisonkun tisonkun merged commit f0646f9 into apache:master Feb 17, 2025
10 checks passed
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.

[CURATOR-718] Refactor CuratorFramework inheritance hierarchy by composing functionalities
2 participants