-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-23683 Make HBaseInterClusterReplicationEndpoint more extensible… #1047
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
…apache#1027) Signed-off-by: Bharath Vissapragada <[email protected]> Signed-off-by: Josh Elser <[email protected]> Signed-off-by: binlijin <[email protected]>
|
💔 -1 overall
This message was automatically generated. |
bharathv
left a comment
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.
Got a question..
| * so defining createReplicationSinkManager as protected for possible overridings. | ||
| */ | ||
| protected ReplicationSinkManager createReplicationSinkManager(Connection conn) { | ||
| return new ReplicationSinkManager((ClusterConnection) conn, this.ctx.getPeerId(), |
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.
nit: redundant cast to conn.
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.
Compilation fails without this cast, as ReplicationSinkManager expects ClusterConnection.
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.
sorry, I meant pass ClusterConnection directly, but I guess that brings us back to your other comment as to why you want to use generic "Connection" object.
| // replication and make replication specific settings such as compression or codec to use | ||
| // passing Cells. | ||
| this.conn = (ClusterConnection) ConnectionFactory.createConnection(this.conf); | ||
| this.conn = (ClusterConnection) createConnection(this.conf); |
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.
Do we need force createConnection() to return a connection of type ClusterConnection? Otherwise, theoretically overrides can return any type of Connection (may or may not be ClusterConnection) and the type cast here fails. Just a thought.
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.
Yeah, that kind of restrict the extensibility, which is what we are trying to improve here, but addressing that would require an extra refactoring effort, just as @joshelser mentioned on the master PR. For example, in master branch, we are forced to return AsyncClusterConnection.
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.
that kind of restrict the extensibility, which is what we are trying to improve here,
Hmm.. May be I'm missing something, what does your use case look like here where you have an override that does a generic Connection rather than (some type of) ClusterConnection? I'm curious how it restricts extensibility because to use this, it has to be a ClusterConnection, otherwise it fails at runtime, no?
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.
what does your use case look like here where you have an override that does a generic Connection rather than (some type of) ClusterConnection?
I have a HBaseInterClusterReplicationEndpoint extension where I'm still using ConnectionFactory for creating connections, but I use different factory method than what is used by HBaseInterClusterReplicationEndpoint. I don't really care about which connection implementation the factory is returning, I just rely on whatever is the default (in 2.x, it's ClusterConnection). I noticed, though, that default connection type changed between 2.x and 3.0, from ClusterConnection to AsycnClusterConnection. So, if we keep create methods referencing generic Connection only, I won't need to change my HBaseInterClusterReplicationEndpoint extension if I upgrade to hbase 3.x (provided, of course, that HBaseInterClusterReplicationEndpoint.conn variable also changes to same default returned by ConnectionFactory).
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.
Oh I see.. I think I get the problem. Basically you are just relying on ConnectionFactory and not worried about the type it is returning. Ya, refactoring it will be a bigger patch.
nit: How about adding a preconditions check.. Preconditions.checkState(returnedConn instanceof ClusterConnection) and back it up with a comment why it could fail?
| private boolean isSerial = false; | ||
|
|
||
| /* | ||
| * Some implementations of HBaseInterClusterReplicationEndpoint may require instantiate different |
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.
nit: instantiating..
bharathv
left a comment
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.
I'm +1 once my nits are addressed. Thanks for patiently answering my questions.
| // replication and make replication specific settings such as compression or codec to use | ||
| // passing Cells. | ||
| this.conn = (ClusterConnection) ConnectionFactory.createConnection(this.conf); | ||
| this.conn = (ClusterConnection) createConnection(this.conf); |
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.
Oh I see.. I think I get the problem. Basically you are just relying on ConnectionFactory and not worried about the type it is returning. Ya, refactoring it will be a bigger patch.
nit: How about adding a preconditions check.. Preconditions.checkState(returnedConn instanceof ClusterConnection) and back it up with a comment why it could fail?
|
Thanks for the suggestions, @bharathv , had addressed it on last commit. @joshelser @binlijin , would you guys think this is good to go on branch-2? I think we would also need an addendum commit for master branch with the generic Connection reference and @bharathv last suggestions. |
|
💔 -1 overall
This message was automatically generated. |
|
The checkstyle import order complaint doesn't look correct. |
Try moving "import org.apache.hbase.thirdparty.com.google.common.base.Preconditions" towards the end..It is likely because we enforce grouping for this third party package. |
bharathv
left a comment
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.
Thanks for addressing my comments.
binlijin
left a comment
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.
LGTM +1
Let's give it a try. |
|
🎊 +1 overall
This message was automatically generated. |
#1047) Signed-off-by: Bharath Vissapragada <[email protected]> Signed-off-by: binlijin <[email protected]> (cherry picked from commit 62e3409)
apache#1047) Signed-off-by: Bharath Vissapragada <[email protected]> Signed-off-by: binlijin <[email protected]>
apache#1047) Signed-off-by: Bharath Vissapragada <[email protected]> Signed-off-by: binlijin <[email protected]> (cherry picked from commit 62e3409) (cherry picked from commit 877564c) Change-Id: I3b1d5c76861465059aa3df2b679c91f6e5f20bb1
… (#1027)
Had opened a separate PR for branch-2, as it doesn't have AsyncClusterConnection, requiring changes on basically the whole connection creation code. One thought I had just after I had already merged previous PR in master is that the two additional create methods should refer to Connection, instead of ClusterConnection or AsyncClusterConnection, as that would shield HBaseInterClusterReplicationEndpoint extensions from changes between 2.x and 3.x.
Ping @bharathv