-
Notifications
You must be signed in to change notification settings - Fork 438
RATIS-1798. Make ratis-shell command respect GENERIC_COMMAND_OPTIONS #834
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
kaijchen
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, thanks @AngersZhuuuu.
codings-dan
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 working on this! the change looks good, +1
|
The failed test seems not related |
| // set these options to raft properties to make it work. | ||
| System.getProperties().stringPropertyNames().forEach( | ||
| key -> properties.setIfUnset(key, System.getProperty(key))); | ||
| RaftClientConfigKeys.Rpc.setRequestTimeout(properties, |
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.
@AngersZhuuuu , thanks for working on this! This is a good change. We should check if the requestTimeout is already set.
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.
We should check if the requestTimeout is already set.
How about the current change? Properties in System should have higher priority. It can cover the requestTimeout if we set it passed by -D
szetszwo
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.
+1 the change looks good.
tisonkun
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.
Generally looks good. One comment here:
- It can be better to support properties merge for
RaftProperties, like:
diff --git a/ratis-common/src/main/java/org/apache/ratis/conf/RaftProperties.java b/ratis-common/src/main/java/org/apache/ratis/conf/RaftProperties.java
index f51bc731..a0f19899 100644
--- a/ratis-common/src/main/java/org/apache/ratis/conf/RaftProperties.java
+++ b/ratis-common/src/main/java/org/apache/ratis/conf/RaftProperties.java
@@ -18,6 +18,8 @@
package org.apache.ratis.conf;
+import java.util.Properties;
+import org.apache.ratis.thirdparty.com.google.common.collect.Maps;
import org.apache.ratis.util.JavaUtils;
import org.apache.ratis.util.ReflectionUtils;
import org.apache.ratis.util.SizeInBytes;
@@ -53,6 +55,10 @@ public class RaftProperties {
public RaftProperties() {
}
+ public RaftProperties(Properties properties) {
+ this.properties.putAll(Maps.fromProperties(properties));
+ }
+
/**
* A new RaftProperties with the same settings cloned from another.
*
@@ -124,6 +130,24 @@ public class RaftProperties {
return result;
}
+ /**
+ * Merge two raft properties.
+ *
+ * <p>
+ * Properties in {@code p2} overwrite those in {@code p1} if they have
+ * the same key.
+ * </p>
+ *
+ * @param p1 first properties
+ * @param p2 second properties
+ * @return merged properties
+ */
+ public static RaftProperties merge(RaftProperties p1, RaftProperties p2) {
+ RaftProperties result = new RaftProperties(p1);
+ result.properties.putAll(p2.properties);
+ return result;
+ }
+
/**
* Attempts to repeatedly expand the value {@code expr} by replacing the
* left-most substring of the form "${var}" in the following precedence order
diff --git a/ratis-shell/src/main/java/org/apache/ratis/shell/cli/RaftUtils.java b/ratis-shell/src/main/java/org/apache/ratis/shell/cli/RaftUtils.java
index dfbfdd32..6881b4a6 100644
--- a/ratis-shell/src/main/java/org/apache/ratis/shell/cli/RaftUtils.java
+++ b/ratis-shell/src/main/java/org/apache/ratis/shell/cli/RaftUtils.java
@@ -64,8 +64,8 @@ public final class RaftUtils {
* @return return a raft client
*/
public static RaftClient createClient(RaftGroup raftGroup) {
- RaftProperties properties = new RaftProperties();
- RaftClientConfigKeys.Rpc.setRequestTimeout(properties,
+ RaftProperties defaults = new RaftProperties();
+ RaftClientConfigKeys.Rpc.setRequestTimeout(defaults,
TimeDuration.valueOf(15, TimeUnit.SECONDS));
ExponentialBackoffRetry retryPolicy = ExponentialBackoffRetry.newBuilder()
.setBaseSleepTime(TimeDuration.valueOf(1000, TimeUnit.MILLISECONDS))
@@ -73,9 +73,12 @@ public final class RaftUtils {
.setMaxSleepTime(
TimeDuration.valueOf(100_000, TimeUnit.MILLISECONDS))
.build();
+
+ RaftProperties systems = new RaftProperties(System.getProperties());
+
return RaftClient.newBuilder()
.setRaftGroup(raftGroup)
- .setProperties(properties)
+ .setProperties(RaftProperties.merge(defaults, systems))
.setRetryPolicy(retryPolicy)
.build();
}But it's more on style preference, so committers make the call.
|
May I ask which RPC implementation is favored in the downstream projects or production cases? Are there general pros and cons of each one? |
|
@pan3793 This question is unrelated to this patch. I suggest you email to [email protected] for discussion. See this page about how to subscribe the list. |
Actually, this issue is found in the Celeborn project when we want to include @tisonkun Based on this fact, I think they are kind of "related". |
https://issues.apache.org/jira/browse/RATIS-1412 But Netty should be supported as well. Glad to see we have Netty use cases in Celeborn. |
|
Thank @kaijchen for the information, yes, it works after this minor fix, I know you are active in the Ozone community, would you like to share more about why Ozone uses gRPC by default? |
Basically gRPC is higher level and provides more features, while Netty is lower level and has less overhead. There is a blog post about why Alluxio switch from Thrift + Netty to gRPC: |
|
Many thanks, @kaijchen |
@kaijchen The link seems broken. IoTDB community also had a discussion about Thrift v.s gRPC recently. It would be great to learn lessons from other projects. @pan3793 IoTDB also uses gRPC by default. It was originally a "captain's call" ;). gRPC mostly meets our needs. However, we are experiencing issues related to gRPC's installSnapshot process recently. |
|
@SzyWilliam thanks for the information, looks like the gRPC protocol has more practices. BTW, I can open the link
|
You need to set language to EN first: https://www.alluxio.io/?lang=en |
@pan3793 , thanks for being interested in Apache Ratis! I agree with @tisonkun that this kind of questions is better to discuss it on the mailing list. Let me give you some short answer. Currently, grpc is the default rpc type in Ratis. It supports all the functionalities -- blocking io, ordered async and unordered async. Netty RPC in Ratis only supports blocking io. From our experience, grpc is good when the message sizes are small. For large messages, grpc does not perform well since we cannot control the buffer allocation and copying. Netty is better in that case. |
@kaijchen , thanks for sharing the blog!
Do you have more details on zero-copy? I wonder if we could do the same in Ratis. |
|
|
||
| // Since ratis-shell support GENERIC_COMMAND_OPTIONS, here we should | ||
| // merge these options to raft properties to make it work. | ||
| RaftProperties systems = new RaftProperties(System.getProperties()); |
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.
@AngersZhuuuu , let's simply use forEach instead of changing RaftProperties.
@@ -67,6 +68,12 @@ public final class RaftUtils {
RaftProperties properties = new RaftProperties();
RaftClientConfigKeys.Rpc.setRequestTimeout(properties,
TimeDuration.valueOf(15, TimeUnit.SECONDS));
+
+ // Since ratis-shell support GENERIC_COMMAND_OPTIONS, here we should
+ // merge these options to raft properties to make it work.
+ final Properties sys = System.getProperties();
+ sys.stringPropertyNames().forEach(key -> properties.set(key, sys.getProperty(key)));
+
ExponentialBackoffRetry retryPolicy = ExponentialBackoffRetry.newBuilder()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.
DOne
|
@szetszwo, thank you for sharing the detail, based on your description, the gRPC should be the best choice for Apache Celeborn(Incubating). |
Alluxio/alluxio#8353 You may also check: GoogleCloudPlatform/grpc-gcp-java#77 AFAIK, it is still not as good as Netty though. |
|
@kaijchen , thanks for the info. Will check them. |
szetszwo
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.
+1 the change looks good.
What changes were proposed in this pull request?
Our ratis cluster use NETTY rpc, since default RPC is GRPC, when we want to use ratis shell to change leader
we use below command
Found GENERIC_COMMAND_OPTIONS can't work well.
This pr resolve this issue.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/RATIS-1798
Please replace this section with the link to the Apache JIRA)
How was this patch tested?
Tested in our env