Question

16:37:21.945 [Workflow Executor taskList="PullFulfillmentsTaskList", domain="test-domain": 3] WARN com.uber.cadence.internal.common.Retryer - Retrying after failure
org.apache.thrift.transport.TTransportException: Request timeout after 1993ms
    at com.uber.cadence.serviceclient.WorkflowServiceTChannel.throwOnRpcError(WorkflowServiceTChannel.java:546)
    at com.uber.cadence.serviceclient.WorkflowServiceTChannel.doRemoteCall(WorkflowServiceTChannel.java:519)
    at com.uber.cadence.serviceclient.WorkflowServiceTChannel.respondDecisionTaskCompleted(WorkflowServiceTChannel.java:962)
    at com.uber.cadence.serviceclient.WorkflowServiceTChannel.lambda$RespondDecisionTaskCompleted$11(WorkflowServiceTChannel.java:951)
    at com.uber.cadence.serviceclient.WorkflowServiceTChannel.measureRemoteCall(WorkflowServiceTChannel.java:569)
    at com.uber.cadence.serviceclient.WorkflowServiceTChannel.RespondDecisionTaskCompleted(WorkflowServiceTChannel.java:949)
    at com.uber.cadence.internal.worker.WorkflowWorker$TaskHandlerImpl.lambda$sendReply$0(WorkflowWorker.java:301)
    at com.uber.cadence.internal.common.Retryer.lambda$retry$0(Retryer.java:104)
    at com.uber.cadence.internal.common.Retryer.retryWithResult(Retryer.java:122)
    at com.uber.cadence.internal.common.Retryer.retry(Retryer.java:101)
    at com.uber.cadence.internal.worker.WorkflowWorker$TaskHandlerImpl.sendReply(WorkflowWorker.java:301)
    at com.uber.cadence.internal.worker.WorkflowWorker$TaskHandlerImpl.handle(WorkflowWorker.java:261)
    at com.uber.cadence.internal.worker.WorkflowWorker$TaskHandlerImpl.handle(WorkflowWorker.java:229)
    at com.uber.cadence.internal.worker.PollTaskExecutor.lambda$process$0(PollTaskExecutor.java:71)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)

我们的父工作流程代码基本上是这样的（JSONObject来自org.json）

JSONObject[] array = restActivities.getArrayWithHugeJSONItems();
for(JSONObject hugeJSON: array) {
  ChildWorkflow child = Workflow.newChildWorkflowStub(ChildWorkflow.class);
  child.run(hugeJSON);
}

我们发现，在大多数情况下，父工作流程工作人员无法启动子工作流程，并在上面抛出了超时异常。它像疯狂一样重试，但是永远不会成功，并且一遍又一遍地打印超时异常。但是有时候我们很幸运，并且可以正常工作。有时，它甚至在活动工作程序中更早失败，并且引发相同的异常。我们认为这是由于数据太大（约5MB），并且无法在超时时间内发送（从我们认为该日志设置为2s的日志中判断）。如果我们用伪造的小数据调用child.run，则100％可以正常工作。

我们使用子工作流程的原因是我们想使用Async.function来并行运行它们。那么如何解决这个问题呢？是否应该增加节俭的超时配置，或者以某种方式避免传递大量数据？

提前谢谢！

---在Maxim回答后更新---

谢谢。我阅读了示例，但是对于我的用例仍然有一些疑问。假设我在RestActivitiesWorker中得到了一个包含100个巨大JSON对象的数组，如果我不应该将巨大的数组返回给工作流，则需要对数据库进行100次调用以创建100行记录并将100个id放入一个数组中，将其传递回工作流程。然后，工作流为每个ID创建一个子工作流。然后，每个子工作流程都会调用另一个具有ID的活动，以从数据库加载数据。但是该活动必须将巨大的JSON传递给子工作流程，这样行吗？对于在数据库中插入100次的RestActivitiesWorker，如果中间失败了怎么办？

我想可以归结为我们的工作流正在尝试直接使用巨大的JSON。我们正在尝试从外部系统将巨大的JSON（5-30MB，不是那么大）加载到我们的系统中。我们稍微分解一下JSON，处理一些值，并使用一些字段中的值执行一些不同的逻辑，最后将其保存在数据库中。我们应该如何用Temporal做到这一点？

Answer 1

Temporal / Cadence不支持将大型Blob用作输入和输出，因为它使用DB作为基础存储。因此，您想更改应用程序的体系结构以避免这种情况。

标准解决方法是：

使用外部Blob存储来保存大数据，并将对它的引用作为参数传递。
在工作进程甚至主机磁盘中缓存数据，并将对此数据进行操作的活动路由到该进程或主机。有关这种方法，请参见文件处理示例。

子工作流程的输入量很大时发生超时异常

1 个答案: