Thrift异步函数中的回调? [英] Callbacks in Thrift Asynchronous Functions?
问题描述
显然,当函数的执行完成时,无法定义回调。
似乎我唯一可能的是给我的Thrift客户端( PHP )一些服务器功能,这样,当在服务器端完成繁重的计算,我可以发送通知给它。这意味着我应该有一个新的.thrift文件,新的定义,新的服务和所有其余的,我应该生成php服务器端代码与Thrift。
即使这是可行的,它看起来像一个overkill我,我想知道是否有一个更聪明的方式来实现回调。
期待一些反馈你,伙计。
不幸的是Thrift框架没有这样的内置功能。但是,根据您希望PHP客户端会话在您通常等待计算密集型Thrift服务器回答的时间(您没有使用过),您可能会有一些替代方案 oneway
。)
我现在只能想象, web应用程序,其中用户(或并行的多个用户)可以各自触发计算密集型任务,您希望在所述任务改变时向所述用户提供一些反馈。
从一开始,你是绝对正确的,试图避免你试图避免的解决方案。您的PHP客户端会话无法在未阻止的情况下处理回调接口(除非您通过尝试使用 pcntl_fork 或其他 PHP threading band-aid 。)
最简单的IMHO最好的方法是两个从事件驱动模型切换(我想在服务器完成时通知)到轮询模型将定期向服务器询问是否完成。)有几种方式实现轮询模型,在服务器以及客户端上具有多个实现选项,例如:
在调用阶段期间,-
:
- PHP客户端会话分配唯一的
job_id
值;然后会话使得计算密集型Thrift服务器的异步oneway
调用void compute(...,job_id)
,
- 或 - b
- PHP客户端会话进行同步调用
job_id start_compute(...)
到计算密集型Thrift服务器;服务器分配唯一的job_id
值,然后在单独的线程/进程中生成实际的计算密集型任务,立即返回到具有分配的<$ c的PHP客户端会话在计算阶段期间,$ c> job_id
- PHP客户端会话分配唯一的
- PHP客户端会话通过同步 <$ c定期检查计算密集型任务的状态$ c> status get_status(job_id)呼叫计算密集型Thrift伺服器,
- PHP客户端会话立即终止,以释放在将
job_id
传递给浏览器并且还指示浏览器周期性地检查计算密集型作业的状态job_id
(例如通过META REFRESH
,或通过来自Javascript的XHR(AJAX)请求等);浏览器检查产生一个简短的PHP客户端会话,它执行对计算密集型Thrift服务器的同步状态get_status(job_id)
调用,
-
In Thrift it is possible to use the oneway modifier to specify a call as asynchronous.
Apparently, it's not possible to define a callback, though, to be executed when the execution of the function is completed.
It seems that the only possibility I have is to give my Thrift client (PHP) some "server" capabilities, so that, when the heavy computation is completed on the server side, I can send a notification to it. This means that I should have a new .thrift file, with new definitions, new services and all the rest and that I should generate php-server side code with Thrift.
Even if this is feasible, it looks like an overkill to me and I'm wondering if there's a more clever way to implement the callback.
Looking forward for some feedback from you, guys.
Roberto, unfortunately the Thrift framework has no such built-in functionality. There may be a number of alternatives, though, depending on what you want your PHP client session to do during the time you would normally have waited for the computationally-intensive Thrift server to answer (had you not used oneway
.)
I can only imagine, for now, that you are in a situation where, having coded a web application where a user (or several users in parallel) can each trigger a computationally-intensive task, you would like to provide some feedback to said users while said tasks churn along.
From the start, you are absolutely right in trying to avoid the solution that you are trying to avoid. Your PHP client sessions cannot service a callback interface without blocking (unless you dig your hole even deeper by trying to use pcntl_fork or some other PHP threading band-aid.)
The simplest and IMHO best way out of this is two switch from an event-driven model (I want to be notified when the server is done) to a polling model (I will periodically inquire with the server whether or not it is done.) There are several ways of implementing a polling model, with multiple implementation options on the server as well as on the client sides, such as:
during the invocation phase:
- the PHP client session allocates a unique
job_id
value; the session then makes the asynchronousoneway
callvoid compute(..., job_id)
to the computationally-intensive Thrift server,
-- or --
- the PHP client session makes a synchronous call
job_id start_compute(...)
to the computationally-intensive Thrift server; the server allocates the uniquejob_id
value, then spawns the actual computationally-intensive task in a separate thread/process, returning right away to the PHP client session with the allocatedjob_id
- the PHP client session allocates a unique
during the computation phase:
- the PHP client session proceeds to periodically check the status of the computationally-intensive job via a synchronous
status get_status(job_id)
call to the computationally-intensive Thrift server,
-- or --
- the PHP client session terminates right away in order to free up precious resources, after passing on the
job_id
to the browser and also instructing the browser to periodically check the status of the computationally-intensive jobjob_id
(e.g. viaMETA REFRESH
, or via an XHR (AJAX) request from Javascript, etc.); the browser check spawns a brief PHP client session which performs the synchronousstatus get_status(job_id)
call to the computationally-intensive Thrift server, terminating immediately after forwarding the status (whichever it may be) on to the browser
- the PHP client session proceeds to periodically check the status of the computationally-intensive job via a synchronous
这篇关于Thrift异步函数中的回调?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!