Thrift 异步函数中的回调？
在 Thrift 中，可以 使用oneway修饰符将调用指定为异步。
显然，无法定义要在函数执行完成时执行的回调。
看来我唯一的可能就是给我的Thrift客户端（PHP）一些“服务器”能力，这样，当服务器端完成繁重的计算时，我可以向它。这意味着我应该有一个新的 .thrift 文件，其中包含新定义、新服务和所有其他内容，并且我应该使用 Thrift 生成 php 服务器端代码。
即使这是可行的，对我来说这看起来有点矫枉过正，我想知道是否有更聪明的方法来实现回调。
期待你们的一些反馈，伙计们。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Roberto，不幸的是 Thrift 框架没有这样的内置功能。不过，可能有多种替代方案，具体取决于您希望 PHP 客户端会话在您通常等待计算密集型 Thrift 服务器应答期间执行的操作（如果您没有使用
oneway。）目前，我只能想象您所处的情况是，在编写了一个 Web 应用程序后，一个用户（或多个并行用户）可以各自触发一个计算密集型任务，您想在所述任务进行时向所述用户提供一些反馈。
从一开始，你试图避免你试图避免的解决方案是绝对正确的。您的 PHP 客户端会话无法在不阻塞的情况下为回调接口提供服务（除非您尝试使用 pcntl_fork 或其他一些 PHP 线程创可贴。）
最简单也是恕我直言最好的解决方法是两个从事件驱动模型切换（< em>我希望在服务器完成时收到通知）轮询模型（我会定期询问服务器是否完成。 ) 实现轮询模型的方法有多种，在服务器端和客户端都有多种实现选项，例如：
在调用阶段：
job_id值；然后，会话对计算密集型 Thrift 服务器进行异步oneway调用voidcompute(..., job_id)，-- 或 --
job_id start_compute(...)；服务器分配唯一的 job_id 值，然后在单独的线程/进程中生成实际的计算密集型任务，并立即返回带有分配的 job_id 的 PHP 客户端会话< /里>status get_status(job_id)调用定期检查计算密集型作业的状态，-- 或 --
job_id传递给浏览器并指示浏览器定期检查计算密集型作业的状态后，PHP 客户端会话立即终止，以释放宝贵的资源< code>job_id（例如通过META REFRESH，或者通过来自 Javascript 的 XHR (AJAX) 请求等）；浏览器检查会生成一个简短的 PHP 客户端会话，该会话执行对计算密集型 Thrift 服务器的同步status get_status(job_id)调用，在转发状态后立即终止（无论是哪个状态）可能）在浏览器上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:
job_idvalue; the session then makes the asynchronousonewaycallvoid compute(..., job_id)to the computationally-intensive Thrift server,-- or --
job_id start_compute(...)to the computationally-intensive Thrift server; the server allocates the uniquejob_idvalue, then spawns the actual computationally-intensive task in a separate thread/process, returning right away to the PHP client session with the allocatedjob_idduring the computation phase:
status get_status(job_id)call to the computationally-intensive Thrift server,-- or --
job_idto 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我在不同于 Stack Overflow 的渠道上收到了答复。由于作者允许我在这里发布他的答案，我认为这对社区中的其他人可能有用。
I've received an answer on a channel different from Stack Overflow. Since the author gave me permission to post here his answer, I thought it could be useful to someone else in the community.
我没有尝试使用 Thrift 实现回调（我猜这会使协议变得更重），而是使用轻量级消息服务（STOMP - http://stomp.github.com) 通知客户端异步事件。
我的方法是，Thrift 客户端订阅特定的 STOMP 通道，而每当异步事件发生时，Thrift 服务器就会在同一通道上发布消息。然后，客户端可以向服务器查询有关该事件的附加信息。
Instead of trying to implement callbacks with Thrift (something that would have made the protocol significanty heavier I guess), I use a lightweight messaging service (STOMP - http://stomp.github.com) to inform the client of asynchronous events.
My approach is that the Thrift client subscribes to a specific STOMP channel, and the Thrift server will post on that same channel whenever an asynchronous event occurs. The client then can query the server for additional info about the event.
Java 通过 Future 对象引用进行异步消息调用。这可以使用 消息包 在 RPC 模型中实现。我不确定 PHP 是否有类似的东西。
Well Java has Asynchronus Message calls through Future Object reference. This can be implemented in a RPC model using Message Pack. I am not sure if PHP has something similar.