-
Couldn't load subscription status.
- Fork 3.4k
HBASE-28425 Allow specify cluster key without zookeeper in replication #5865
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,6 +19,7 @@ | |
|
|
||
| import java.io.IOException; | ||
| import java.net.URI; | ||
| import org.apache.commons.lang3.StringUtils; | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, I forget which dependencies we expose transitively. Should we be using a shaded version of this class? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let me check if we have commons-lang3 shaded. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We do not shade commons-lang3 in hbase-thirdparty There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay thanks for checking. I wonder if we should. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Commons-lang3 is not likely to introduce big conflicts. It changed its package name to commons-lang3 from commons-lang when introducing breaking changes. |
||
| import org.apache.hadoop.conf.Configuration; | ||
| import org.apache.hadoop.hbase.security.User; | ||
| import org.apache.yetus.audience.InterfaceAudience; | ||
|
|
@@ -46,4 +47,12 @@ public ConnectionRegistry create(URI uri, Configuration conf, User user) throws | |
| public String getScheme() { | ||
| return "hbase+rpc"; | ||
| } | ||
|
|
||
| @Override | ||
| public void validate(URI uri) throws IOException { | ||
| if (StringUtils.isBlank(uri.getAuthority())) { | ||
| throw new IOException("no bootstrap nodes specified, uri: " + uri); | ||
| } | ||
| // TODO: add more check about the bootstrap nodes | ||
| } | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -86,6 +86,14 @@ public class TestVerifyReplication extends TestReplicationBase { | |
| @Rule | ||
| public TestName name = new TestName(); | ||
|
|
||
| @Override | ||
| protected String getClusterKey(HBaseTestingUtil util) throws Exception { | ||
| // TODO: VerifyReplication does not support connection uri yet, so here we need to use cluster | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there an issue filed for this TODO? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. thanks! |
||
| // key, as in this test we will pass the cluster key config in peer config directly to | ||
| // VerifyReplication job. | ||
| return util.getClusterKey(); | ||
| } | ||
|
|
||
| @Before | ||
| public void setUp() throws Exception { | ||
| cleanUp(); | ||
|
|
||
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.
Maybe this interface should be
boolean isValid(URI), and then the caller is free to throw or not.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.
Throwing exception could let the upper layer know the details about why this is not valid.
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, I understand. This enforces try-catch flow control where if/else would be better. For this kind of thing, I really like the
Resultbased API that is catching on in other languages.Anyway, maybe it should throw something besides
IOException? IllegatStateException, for example?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.
Maybe something like UnsupportedProtocol or IllegalArgument? But IllegalArgument is a RuntimeException, developers may miss to catch it and cause some fatal errors...
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 think a RuntimeException is okay. It happens often enough in the JDK libraries, where they will also add a note about it in the javadoc.
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.
Checked the implementation, now we have these errors
No protocol scheme
No factory registered for the scheme
For zk based registry
Empty zk server string, i.e, empty uri authority
Empty zk parent path, i.e, empty uri path
For rpc based registry
Empty bootstrap nodes, i.e, empty uri authority
In general, there are no accurate exception types for these errors, and since we may add new checks for different registry implementations in the future, I prefer we still keep the
throws IOExceptiondeclaration, and can file new issues to add some specific exceptions which extend HBaseIOException for these cases.