[HUDI-4148] Preparations and client for hudi table manager service #5681

yuzhaojing · 2022-05-25T11:48:24Z

What is the purpose of the pull request

The preparations which changes existing modules for table management service.
The following commits are in #5926.

Brief change log

(for example:)

Add HoodieTableMangerConfig and HoodieTableManagerClient.
Don't execute table services when hoodie.table.management.service.enable = true

Verify this pull request

This pull request is already covered by existing tests.

Committer checklist

Has a corresponding JIRA in PR title & commit
Commit message is descriptive of the change
CI is green
Necessary doc changes done or have another open PR
For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

nsivabalan · 2022-06-09T22:12:11Z

can you please update the description and other elements in the template for the PR

yuzhaojing · 2022-06-15T03:07:21Z

can you please update the description and other elements in the template for the PR

Sure, I will add description for PR later.

YuweiXiao · 2022-05-26T05:27:10Z

...hudi-client-common/src/main/java/org/apache/hudi/table/action/clean/CleanActionExecutor.java

  @Override
  public HoodieCleanMetadata execute() {
+    if (config.isTableManagerEnabled() && config.getTableManagerConfig().getTableManagerActions().contains(ActionType.clean.name())) {
+      LOG.warn("Compaction delegate to table management service, do not clean for client!");


typo, -> 'clean delegate to'

YuweiXiao · 2022-05-26T06:19:13Z

...-common/src/main/java/org/apache/hudi/table/action/cluster/ClusteringPlanActionExecutor.java

+  private void submitClusteringToService() {
+    HoodieTableMetaClient metaClient = table.getMetaClient();
+    List<String> instantsToSubmit = metaClient.getActiveTimeline()
+        .filterPendingReplaceTimeline()


Replace instant may also include insert overwrite operation. Will the manager service double-check to ensure it is a clustering instant?

Yes, we will ensure clustering instant in replaceMetadata operationType. In table manager service we can only deserialize replaceMetadata once.

YuweiXiao · 2022-05-26T06:21:29Z

...mon/src/main/java/org/apache/hudi/table/action/compact/ScheduleCompactionActionExecutor.java

    }
-    return Option.empty();
+
+    if (config.isTableManagerEnabled() && config.getTableManagerConfig().getTableManagerActions().contains(ActionType.compaction.name())) {


Maybe we could abstract this as an interface in config, e.g., isTableManagerIncludeAction(xxx)

Good suggestion, update later.

YuweiXiao · 2022-05-26T06:22:57Z

...lient/hudi-client-common/src/main/java/org/apache/hudi/table/action/HoodieWriteMetadata.java

  // Will be set when auto-commit happens
  private boolean isCommitted;
+  // Will be set when table management service enable
+  private boolean isEmpty;


isEmpty seems a little bit confusing. How about isSkipped?

Good suggestion, update later.

YuweiXiao · 2022-05-26T06:24:33Z

...-client-common/src/main/java/org/apache/hudi/table/action/clean/CleanPlanActionExecutor.java

+    return option;
+  }
+
+  private void submitCleanToService() {


These submit function will submit all pending clean/compaction/clustering instant to the service. What happens if we submit the same instant multiple times?

In the table management service, the received instant will be deduplicated, and the repeatedly accepted instant will not be repeated.

vinothchandar · 2022-06-28T19:02:31Z

@yuzhaojing Can you please fill out the pull request template so we have more context heading into the review?

vinothchandar

Left some comments. Overall - I would prefer is most changes are the client level, rather than the action executors. Overloading code paths there, will make it harder to maintain going forward IMO.

vinothchandar · 2022-06-28T20:06:25Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/config/HoodieWriteConfig.java

    return metadataConfig;
  }

+  public HoodieTableManagerConfig getTableManagerConfig() {


Should we have this as a separate module? That is build on top of hudi-client-common

I think TableManagerConfig is a public config, clients can get it through HoodieWriteConfig, so I think the config in HoodieWriteConfig is better.

vinothchandar · 2022-06-28T20:07:14Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+
+public class HoodieTableManagerClient {
+
+  private static final String BASE_URL = "/v1/hoodie/serivce";


ok, will update.

Please fix the Typo on word service.

vinothchandar · 2022-06-28T20:08:05Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+
+  private static final String BASE_URL = "/v1/hoodie/serivce";
+
+  public static final String REGISTER = String.format("%s/%s", BASE_URL, "register");


Add a _ENDPOINT to the names, so its clear what this is?

REGISTER_ENDPOINT

ok, will update it.

vinothchandar · 2022-06-28T20:09:11Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+
+  private static int failTimes;
+
+  private static final Logger LOG = LogManager.getLogger(HoodieTableManagerClient.class);


probably need to rebase this to log4j2 now

will update it.

We can do this in another MR.

lets actually fix this in this PR please, now that log4j2 is landed.

vinothchandar · 2022-06-28T20:18:19Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+    try {
+      executeRequest(SUBMIT_CLEAN, StringUtils.join(instantsToSubmit.toArray(new String[0]), ","));
+    } catch (Exception e) {
+      LOG.error("Failed to schedule clean to service", e);


can we reuse all this code around exception handling? there is 5 lines of code across the submitXXX methods

Sure, I'll reuse this code.

vinothchandar · 2022-06-28T20:22:50Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+    failTimes = 0;
+  }
+
+  private void checkTolerableSchedule(Exception e) {


overalll I wonder if there is a simpler way of implementing retryable requests

There is already a retry process for request failure, checkTolerableSchedule is just a process to prevent all tasks from failing when table manager service in case have an exception.

vinothchandar · 2022-06-28T20:24:29Z

...hudi-client-common/src/main/java/org/apache/hudi/table/action/clean/CleanActionExecutor.java

  @Override
  public HoodieCleanMetadata execute() {
+    if (config.isTableManagerEnabled() && config.getTableManagerConfig().getTableManagerActions().contains(ActionType.clean.name())) {
+      LOG.warn("Compaction delegate to table management service, do not clean for client!");


this is cleaning? Can we check all log messages like this

vinothchandar · 2022-06-28T20:52:04Z

...-client-common/src/main/java/org/apache/hudi/table/action/clean/CleanPlanActionExecutor.java

    }
-    return Option.empty();
+
+    if (config.isTableManagerEnabled() && config.getTableManagerConfig().getTableManagerActions().contains(ActionType.clean.name())) {


Instead of leaking the table management service into the action executors., can we layer it on top? Introduce a higher level write config say hoodie.enable.table.services, (default: true) which when set to false will not do any scheduling/execution of any table services. This check can be added at the BaseHoodieWriteClient level when the calls are made for clean, scheduleClean, compact, scheduleCompact etc.

We can then instruct the users to set hoodie.enable.table.services=false when running with Table management services. Another point here is that we should check for some lock manager being configured when operating in this mode, so that there is no race between delta commits and compaction scheduling.

This is a cleaner implementation, I will modify the implementation.
But I don't want to introduce a lock manager in the current version, it is too heavy for the user.

vinothchandar · 2022-06-28T20:56:13Z

...-client-common/src/main/java/org/apache/hudi/table/action/clean/CleanPlanActionExecutor.java

+
+  private void submitCleanToService() {
+    HoodieTableMetaClient metaClient = table.getMetaClient();
+    List<String> instantsToSubmit = metaClient.getActiveTimeline()


Hmmm. based on this, do you intend to have the scheduling done by the writer still and only move execution to the Table manager service?

We plan to schedule plan and move execution to tms by writer in tms phase1, and support schedule in tms in tms phase2. Because the current concurrency control needs to introduce external dependencies, but we can reserve parameters in the core api. WDYT

vinothchandar · 2022-06-28T20:57:30Z

...in/java/org/apache/hudi/table/action/cluster/SparkExecuteClusteringCommitActionExecutor.java

  @Override
  public HoodieWriteMetadata<HoodieData<WriteStatus>> execute() {
+    if (config.isTableManagerEnabled() && config.getTableManagerConfig().getTableManagerActions().contains(ActionType.replacecommit.name())) {
+      LOG.warn("Clustering delegate to table management service, do not cluster for client!");


Can we avoid invoking this code path from the client level, rather than returning an empty writeMetadata object

Sure, will update it.

yuzhaojing · 2022-06-29T01:28:13Z

@vinothchandar Thanks for review, I'll fill in the template later and consider an updated scenario based on the comments.

yuzhaojing · 2022-07-06T16:13:31Z

@vinothchandar Modified some code, Major changes:

Extract validation logic from action executor to BaseHoodieWriteClient.
Removed failure tolerance logic.

yuzhaojing · 2022-07-06T16:14:39Z

@suryaprasanna Could you please take a look？

XuQianJin-Stars · 2022-07-12T01:46:53Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/BaseHoodieWriteClient.java

+        } else {
+          runAnyPendingCompactions(table);
+          inlineCompaction(extraMetadata);
+        }


L552-L557 Extract into a method?

will update.

XuQianJin-Stars · 2022-07-12T01:47:16Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/BaseHoodieWriteClient.java

+          scheduleClustering(extraMetadata);
+        } else {
+          runAnyPendingClustering(table);
+          inlineClustering(extraMetadata);


will update.

XuQianJin-Stars · 2022-07-12T01:49:23Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/BaseHoodieWriteClient.java

      }

+      if (delegateToTableManagerService(config, ActionType.clean)) {
+        return null;


Why is null returned here?

Because the clean action has not been carried out at this time. So the cleanMetadata is null.

XuQianJin-Stars · 2022-07-12T01:55:50Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+  public static final String SUBMIT_COMPACTION = String.format("%s/%s", BASE_URL, "compact/submit");
+  public static final String REMOVE_COMPACTION = String.format("%s/%s", BASE_URL, "compact/remove");
+
+  public static final String SUBMIT_CLUSTERING = String.format("%s/%s", BASE_URL, "cluster/submit");


submit -> create remove -> delete ?
https://cloud.google.com/apis/design/standard_methods

will update.

suryaprasanna · 2022-07-13T05:39:54Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+
+public class HoodieTableManagerClient {
+
+  private static final String BASE_URL = "/v1/hoodie/serivce";


Please fix the Typo on word service.

suryaprasanna · 2022-07-13T06:28:47Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+  public void submitClustering() {
+    try {
+      metaClient.reloadActiveTimeline();
+      String instantRange = StringUtils.join(ClusteringUtils.getPendingClusteringInstantTimes(metaClient)


I noticed that whenever an action is scheduled, instead of sending that particular instant, we are sending all the pending instants for that action as part of the request. This would mean the remote client has to iterate over the instants and update the contents to the mysql/hudi db.

I am guessing this was done so that in case an action is scheduled but failed to update the table service, then the .requested instant will be left on the timeline.

One way we are trying to workaround this is by sending the request before creating .requested files.

Timeline of actions will look like this,

Generate clustering/compaction plan for an instant x

After plan is generated, send request to table service for the instant x

Create x.clustering.requested or x.compaction.requested file on the timeline

In case the request is successfully send to table service and the .requested file creation failed then it will be treated as a no-op by table service when it schedules the job. There is a possibility that table service can execute right after point 2, but it can be handled by introducing some delay.

This above approach is useful, if we want to send any spark job specific parameters to the table service for executing that instants, example no. of executors. Since, no.of executors can vary depending on the plan.

This will cause two problems:

When the table service is unavailable, the timeline will not be able to generate the requested instant, so it will not be able to operate when the table service is restored, which has a greater impact on the day level write job.

When the table service receives the request, it needs to scan the timeline corresponding to the hudi table to determine whether it is invalid, which will make table management service appear a lot of additional operations.

Considering these two points, I think sending all the pending instant is a better way. WDYT

Here is my understanding, we have 3 components, scheduler(Hudi table via write API), storage (state manager or metaserver(can be mysql or hudi table)) and execution(Table services).

When the table service is unavailable, the timeline will not be able to generate the requested instant, so it will not be able to operate when the table service is restored, which has a greater impact on the day level write job.

If table services is down then there is no one to execute the plan, so no need to create requested file. Initially table generated the plan, similarly it will try to regenerate every time until the table services accepts the request.

There is an advantage to this approach, the latest plan that we generate is also going to include latest changes happened on the table during the period the table service is down.

When the table service receives the request, it needs to scan the timeline corresponding to the hudi table to determine whether it is invalid, which will make table management service appear a lot of additional operations.

I agree, Table service has to be as dumb as possible. Here, it's duty is to read from the storage and execute the spark job. So, basically we are starting the spark job, and the job will not do anything because it cannot find the .requested file for the instant. So, it will just quit.

Another approach, I can think of is to have async thread running that starts on write path and incrementally post the requests to table service reading through the timeline. We can even update file's extrametadata map with any information if needed.

I am inclined with your approach because it is a clean way to do it, but we need to address following things,

I have seen people configure clustering on non-partitioned tables. If we schedule clustering on them and fail to update the table services then no other clustering job will be able to schedule on them because we don't schedule clustering on pending file groups under clustering. So, the replacecommit.requested can be left alone.

Passing job specific parameters like executor count, either we need to pass this information while calling the table service APIs or the table service API need to read through the plan before scheduling a spark job. Ideally we do not want table services to read through clustering plans.

Also, we can schedule clustering jobs on a small group of filegroups one after the other and these clustering plans can be smaller in size and more in number. If table service is running slow, more and more .requested file will be created and more requests will be send to table service.

+1 on keeping the table manager/service decouple as discussed.

Wont' 1 be handled automatically because we resend all the pending instants again to the table manager.

I would imagine 2 to be a config specified at the table manager service level and not passed through from the writer/

there is no backpressure mechanism like what you are describing today. I think your point exists in async clustering/compaction today, regardless of table service or not?

+1 on keeping the table manager/service decouple as discussed.

Wont' 1 be handled automatically because we resend all the pending instants again to the table manager.

I would imagine 2 to be a config specified at the table manager service level and not passed through from the writer/

there is no backpressure mechanism like what you are describing today. I think your point exists in async clustering/compaction today, regardless of table service or not?

+1 from me.

xiarixiaoyao · 2022-07-13T15:20:12Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+      }
+    }
+
+    throw new IOException(String.format("Failed request to table management service %s after retry %d times", url, requestRetryLimit));


maybe it's better to put this exception on line 110

sure, will fixed.

prasannarajaperumal · 2022-07-14T11:50:28Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/BaseHoodieWriteClient.java

    }
  }

+  private void inlineCompaction(HoodieTable table, Option<Map<String, String>> extraMetadata) {


Should we create a clean TableServiceClient abstraction and move all the compaction/clustering/cleaning api into that. We can have multiple engine specific implementation. Thay way we dont combine Write APIs and table services API and avoid multiple if checks here.

+1 on this.

It's a good suggestion, Can we refactor this later？

We just needto co ordinate with RDD APl users like uber, Since it's a breaking change. We can file a code cleanup follow-up JIRA, Orthogonal to this PR?

Reading this again, a separate client impl is probably cleaner even for this PR. These if checks will grow harder to maintain over time.

I have built a Jira to trace, we can do a refactoring of this later, Jira: https://issues.apache.org/jira/browse/HUDI-4407, WDYT?

prasannarajaperumal · 2022-07-14T11:52:00Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/BaseHoodieWriteClient.java

+   * @return Collection of WriteStatus to inspect errors and counts
+   */
+  public HoodieWriteMetadata<O> cluster(String clusteringInstantTime) {
+    if (delegateToTableManagerService(config, ActionType.replacecommit)) {


Refer to my comment above. Would rather have interface having multiple impl than the if conditions here.

Ok, will update.

prasannarajaperumal · 2022-07-14T11:55:29Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/RunsTableService.java

  }
+
+  default boolean delegateToTableManagerService(HoodieWriteConfig config, ActionType actionType) {
+    boolean includeAction = config.isTableManagerIncludeAction(actionType);


isTableManagerIncludeAction -> isTableManagerSupportAction to make it more readable

will update it.

prasannarajaperumal · 2022-07-14T12:01:41Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+/**
+ * Client which send the table service instants to the table management service.
+ */
+public class HoodieTableManagerClient {


Handcoding a HTTP Rest client seems very painful / error prone. Why dont we standardize and pick a framework to support any rest endpoints. Jersey is good one. Lets you enable REST endpoints with annotations, provides exception recovery hooks, testability etc.

We already use javalin and the rest end points generated/wired that way. Can we just reuse that. it will save all the new bundling work needed for a new dependency. @prasannarajaperumal wdyt?

javalin seems okay to me. We should use that here.

prasannarajaperumal · 2022-07-14T12:02:39Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+/**
+ * Client which send the table service instants to the table management service.
+ */
+public class HoodieTableManagerClient {


Need to implement the common HoodieTableServiceClient - Referring to my comment above.

vinothchandar

Left some comments. Overall, much much better. Thanks for making the changes!

vinothchandar · 2022-07-19T13:55:22Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/RunsTableService.java

  }
+
+  default boolean delegateToTableManagerService(HoodieWriteConfig config, ActionType actionType) {
+    boolean supportAction = config.isTableManagerSupportAction(actionType);


rename: is Table Manager Supported Action?

Also can this check move out of WriteConfig? We want to keep methods there pretty light - Small validations on data type conversions

Sure, will move it to TableManagementConfig.

vinothchandar · 2022-07-19T13:55:54Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/RunsTableService.java

  }
+
+  default boolean delegateToTableManagerService(HoodieWriteConfig config, ActionType actionType) {
+    boolean supportAction = config.isTableManagerSupportAction(actionType);


rename: supports Action

vinothchandar · 2022-07-19T22:40:10Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+/**
+ * Client which send the table service instants to the table management service.
+ */
+public class HoodieTableManagerClient {


We already use javalin and the rest end points generated/wired that way. Can we just reuse that. it will save all the new bundling work needed for a new dependency. @prasannarajaperumal wdyt?

vinothchandar · 2022-07-19T22:41:15Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+import org.apache.hudi.common.util.ValidationUtils;
+import org.apache.hudi.exception.HoodieRemoteException;
+
+import org.apache.http.client.fluent.Request;


Can we just align this with how the timeline server is built i.e via javalin instead of the raw HTTP client

Table Manager Service use the javalin, the implemention of HoodieTableManagerClient align with RemoteHoodieTableFileSystemView.

vinothchandar · 2022-07-19T22:42:12Z

...ient-common/src/main/java/org/apache/hudi/client/table/manager/HoodieTableManagerClient.java

+
+  private static int failTimes;
+
+  private static final Logger LOG = LogManager.getLogger(HoodieTableManagerClient.class);


lets actually fix this in this PR please, now that log4j2 is landed.

vinothchandar · 2022-07-20T00:54:45Z

...-common/src/main/java/org/apache/hudi/table/action/cluster/ClusteringPlanActionExecutor.java

    }
+
+    if (config.isTableManagerSupportAction(ActionType.replacecommit)) {
+      createClusteringToService();


rename all such createXXX to delegateXXX to clearly capture what's going on.

will update.

vinothchandar · 2022-07-20T00:56:26Z

...mon/src/main/java/org/apache/hudi/table/action/compact/ScheduleCompactionActionExecutor.java

    }
-    return Option.empty();
+
+    if (config.isTableManagerSupportAction(ActionType.compaction)) {


@prasannarajaperumal can you think any way where can avoid this if switch here. the ActionExecutor hierarchy is pretty deep. So wonder if there is a better way to do without writing a bunch of scaffolding/small subclasses and such/

vinothchandar · 2022-07-20T00:57:16Z

...ient/hudi-spark-client/src/main/java/org/apache/hudi/client/HoodieSparkClusteringClient.java

    LOG.info("Executing clustering instance " + instant);
    SparkRDDWriteClient<T> writeClient = (SparkRDDWriteClient<T>) clusteringClient;
-    Option<HoodieCommitMetadata> commitMetadata = writeClient.cluster(instant.getTimestamp(), true).getCommitMetadata();
+    Option<HoodieCommitMetadata> commitMetadata = writeClient.cluster(instant.getTimestamp()).getCommitMetadata();


who calls this today? Are they are side effects from not forcing the completion?

This is to prevent the user from directly calling the behavior, if it is considered that no user can use it without modification.

vinothchandar · 2022-07-20T00:58:33Z

hudi-common/src/main/java/org/apache/hudi/common/config/HoodieTableManagerConfig.java

+    description = "Configurations used by the Hudi Table Management Service.")
+public class HoodieTableManagerConfig extends HoodieConfig {
+
+  public static final String TABLE_MANAGEMENT_SERVICE_PREFIX = "hoodie.table.management.service";


same feedback. Consistent naming - table.manager.service vs table.management.service. IMHO we can just keep it short as table.manager (its kind of conceivable manager is a service)

vinothchandar · 2022-07-20T00:59:12Z

hudi-flink-datasource/hudi-flink/src/main/java/org/apache/hudi/util/StreamerUtil.java

          .setTableCreateSchema(conf.getString(FlinkOptions.SOURCE_AVRO_SCHEMA))
          .setTableType(conf.getString(FlinkOptions.TABLE_TYPE))
          .setTableName(conf.getString(FlinkOptions.TABLE_NAME))
+          .setDatabaseName(conf.getString(FlinkOptions.DATABASE_NAME))


side effects?

The table service uses db_name.tbl_name to determine the unique hoodie table, but currently Flink does not set it by default db_name.

yuzhaojing · 2022-07-29T08:29:40Z

@hudi-bot run azure

hudi-bot · 2022-07-29T09:21:00Z

CI report:

6566d73 UNKNOWN
a9e0129 Azure: FAILURE

Bot commands

@hudi-bot supports the following commands:

@hudi-bot run azure re-run the last Azure build

xushiyan · 2022-09-19T05:04:59Z

Discussed with @yuzhaojing who has a draft PR abstracting TMS client into a member variable of writeclient. It is not a top-level client as WriteClient but serving the purpose of encapsulating if-checks in one place. I think it is a practical step towards full abstraction of TMS client to the same level as BaseWriteClient, which would involve more many more code changes and not fit into releasing TMS MVP timeline.

xushiyan · 2022-09-21T05:22:40Z

@yuzhaojing let's make sure we link PRs so reviewers know where to follow up

#6732

yuzhaojing · 2022-09-21T05:31:40Z

@yuzhaojing let's make sure we link PRs so reviewers know where to follow up

#6732

Sure, my mistake.

yuzhaojing force-pushed the HUDI-4148 branch 2 times, most recently from 6566d73 to f486cdd Compare May 25, 2022 13:50

yuzhaojing requested a review from vinothchandar May 27, 2022 05:24

yuzhaojing assigned vinothchandar May 27, 2022

yuzhaojing force-pushed the HUDI-4148 branch from f486cdd to 4d37594 Compare May 27, 2022 10:05

yuzhaojing assigned vinothchandar, XuQianJin-Stars and prashantwason and unassigned vinothchandar Jun 1, 2022

yuzhaojing requested review from XuQianJin-Stars, nsivabalan and prashantwason June 1, 2022 15:27

yuzhaojing assigned nsivabalan Jun 1, 2022

nsivabalan added the priority:critical Production degraded; pipelines stalled label Jun 9, 2022

YuweiXiao reviewed Jun 16, 2022

View reviewed changes

xushiyan added priority:blocker Production down; release blocker big-needle-movers and removed priority:critical Production degraded; pipelines stalled labels Jun 21, 2022

vinothchandar requested changes Jun 28, 2022

View reviewed changes

yuzhaojing force-pushed the HUDI-4148 branch from 4d37594 to dee99d0 Compare July 6, 2022 16:07

yuzhaojing closed this Jul 7, 2022

yuzhaojing reopened this Jul 7, 2022

yuzhaojing force-pushed the HUDI-4148 branch 2 times, most recently from 75571c4 to f50bb15 Compare July 11, 2022 07:55

XuQianJin-Stars reviewed Jul 12, 2022

View reviewed changes

suryaprasanna reviewed Jul 13, 2022

View reviewed changes

xiarixiaoyao reviewed Jul 13, 2022

View reviewed changes

prasannarajaperumal requested changes Jul 14, 2022

View reviewed changes

vinothchandar assigned prasannarajaperumal and unassigned nsivabalan Jul 15, 2022

yuzhaojing force-pushed the HUDI-4148 branch from 80f748f to 7ea9c28 Compare July 17, 2022 13:49

vinothchandar reviewed Jul 20, 2022

View reviewed changes

yuzhaojing force-pushed the HUDI-4148 branch 3 times, most recently from dad49f1 to 4da8bf7 Compare July 20, 2022 11:38

codope added priority:critical Production degraded; pipelines stalled and removed priority:blocker Production down; release blocker labels Jul 20, 2022

yuzhaojing force-pushed the HUDI-4148 branch from 4da8bf7 to a9e0129 Compare July 22, 2022 09:12

xushiyan self-assigned this Aug 31, 2022

xushiyan mentioned this pull request Sep 19, 2022

[HUDI-3475] Initialize hudi table management module #5926

Open

[HUDI-4148] Preparations and client for hudi table management service

195a76d

yuzhaojing force-pushed the HUDI-4148 branch from a9e0129 to 195a76d Compare September 21, 2022 02:56

yuzhaojing closed this Sep 21, 2022


		public class HoodieTableManagerClient {

		private static final String BASE_URL = "/v1/hoodie/serivce";


		private static final String BASE_URL = "/v1/hoodie/serivce";

		public static final String REGISTER = String.format("%s/%s", BASE_URL, "register");


		private static int failTimes;

		private static final Logger LOG = LogManager.getLogger(HoodieTableManagerClient.class);

[HUDI-4148] Preparations and client for hudi table manager service #5681

[HUDI-4148] Preparations and client for hudi table manager service #5681

Uh oh!

Conversation

yuzhaojing commented May 25, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is the purpose of the pull request

Brief change log

Verify this pull request

Committer checklist

Uh oh!

nsivabalan commented Jun 9, 2022

Uh oh!

yuzhaojing commented Jun 15, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vinothchandar commented Jun 28, 2022

Uh oh!

vinothchandar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yuzhaojing commented May 25, 2022 •

edited

Loading