我有一个Java RESTful Web服务，将由另一个进程每10秒调用一次。如果条件合适，Web服务需要执行可能广泛的ETL过程（比如10 - 20秒）。但是，我们希望立即返回到调用应用程序，指示有效负载已成功传送到Web服务。
要求摘要：
我已对此进行了编码，但似乎运行正常。但这似乎不对。我创建的线程可能比主Web服务线程运行的时间更长。
有人想指出我这样做的更好方法吗？
答案 0 :(得分：2)
这正是做到这一点的正确方法。关于解决方案“看起来不对”？
我唯一的建议是你不应该只是毫不犹豫地启动线程。你应该有某种共享的ExecutorService来管理这些ETL进程线程。这将使您了解已启动和仍在运行的内容以及限制/控制后台进程数量的能力（并可能处理任何恶意执行）。
您还可能希望为已启动的进程生成某种“jobId”并将其返回给调用者。然后你可以给你的api添加一个调用，客户可以用它来检查一个工作的状态。
答案 1 :(得分：0)
...但是，我们想立即返回调用应用程序 表示有效负载已成功传送到Web服务...
听起来您希望在验证后直接返回成功/失败消息，然后再次包含成功请求的响应。
虽然没有技术原因这不起作用，但在典型的RESTful Web服务交换中，存在一对一的HTTP调用请求比率，该架构可能会因为一个请求可能返回两个响应而中断。这可能会使不是您或您公司的客户感到困惑。
我可能会建议实现一个额外的回调服务，该服务可以与第一个服务请求中返回的故障单异步查询。当您等待返回交易结果时，这具有不阻止服务1的额外好处。
只要您的负载很低，启动该事务的另一个线程就可以了。如果它太高，当你无法启动更多线程时，你的请求将开始超时
答案 2 :(得分：0)
作为替代方案，您可以分离提交任务和执行任务的职责。您已将提交部分关闭 - 您的Web服务收到请求，验证它，但不是产生一个线程来立即执行它，您可以将其保存到外部存储区。
然后在cron上运行一个简单的计划任务（Quartz）来获取新任务并执行它们。
这种方法的优点是更强的解耦和更多的系统灵活性（Web服务关闭不会影响任务执行，反之亦然）。 con是系统中更多的移动部件（组件）。
在任何情况下，您当前的设置都有效，而且您走在正确的轨道上。