OpenCPU中长期运行任务的任务模型? [英] Task model for long-running jobs in OpenCPU?

问题描述

据我所知，OpenCPU中没有任务模型， 即，必须用打开的TCP连接任意等待很长时间，直到请求完成.

To my knowledge, there is no task model in OpenCPU, i.e. one has to wait arbitrarily long with an open TCP connection until the request finishes.

任务模型实现的一种可能性是，当一个人希望运行某个功能时，立即为POST请求返回状态为200 OK的专用任务uri.这样做的好处是，当作业在后台服务器上运行时，客户端将立即获得结果.

One possibility for a task model implementation would be to return a dedicated task uri with status 200 OK immediately for a POST request when one wishes to running a function. The advantage would be that the client would get a result immediately while the job runs on the server in the background.

然后，客户端将轮询任务URI，直到它返回201 created(表示作业已成功完成)或错误代码(未成功调用)为止.在成功的情况下，正文将包含由POST现在直接创建的相同资源列表.

The client would then poll the task URI until it returns 201 created, meaning the job has successfully finished, or an error code for unsuccessful calls. In the success case, the body would contain the same resource list that is created directly by POST now.

对此模型或类似方法有何看法?每个人如何处理?我认为，对于没有开放的TCP连接的长期运行的作业的支持将很有价值.我还想到了一些可选功能，例如在轮询仍在运行的作业时提供进度信息等.

What is the opinion on this model or a similar approach? How does everyone handle this? I think support for long running jobs without open TCP connection would be valuable. Optional features such as supplying progress information while polling the still running job etc. also comes to my mind.

推荐答案

您正确的是，当前版本的OpenCPU不包含任务管理器.客户端在等待请求完成时必须保持连接处于活动状态.对于大多数用例来说，这可以使API保持美观和简单，但对于调度长时间运行的作业而言，并不是最佳选择.但是，所有时间限制都是可配置的，因此没有什么可以阻止您等待30分钟才能完成工作.

You are correct that the current version of OpenCPU does not include a task manager. The client has to keep the connection alive while waiting for the request to finish. This keeps the API nice and simple for the majority of use cases, but it is not optimal for scheduling long running jobs. However all time limits are configurable, so there is nothing stopping you from waiting 30 minutes for your job to finish.

如您所建议，另一种设计是为有效的POST请求返回Accepted 202，然后让客户端轮询结果的状态.这将是对API的一个很酷的补充(也许有一天会被添加)，但是它在客户端和服务器实现中引入了相当多的复杂性.

As you suggest, an alternative design would be to return Accepted 202 for valid POST requests, and then let the client poll for the status of the result. This would be a cool addition to the API (and perhaps will be added one day) but it introduces quite some complexity in the client and server implementations.

在服务器上，您将需要编写任务管理器，并且可能担心监视，超时和手动终止长时间运行的请求的功能.而且，在函数仍在执行时，R不能给您太多信息.例如，实际上没有办法知道函数调用距离完成还有多远.

On the server you would need to write a task manager, and probably worry about functionality to monitor, timeout and manually kill long running requests. Moreover, there is not that much information that R can give you while a function is still executing. For example, there is really no way to know how far a function call is from finishing.

可能的一件事是捕获中间stdout，以便您可以通过定期打印一些状态来在R函数中实现自己的进度指示器.然后，客户端可以重复检索一些URL以读取stdout并查询请求的状态.但是，我怀疑这会有用吗.我很少看到R函数中的进度表(除非debug=TRUE之类的东西)，所以我不确定这对于远程调用的R函数有什么不同.

One thing that would be possible is to capture intermediate stdout, so that you could implement your own progress indicator in the R function by regularly printing some status. The client could then repeatedly retrieve some URL to read stdout and inquire about the status of the request. However I doubt how useful this would be. I rarely see progress meters in R functions (unless debug=TRUE or something), so I am not sure this would be any different for R functions that are called remotely.

这篇关于OpenCPU中长期运行任务的任务模型?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！