取消 gwt rpc 调用
在这个示例中，有一个关于如何制作使用 Timer#schedule 的超时逻辑。但这里有一个陷阱。我们有 2 个 rpc 请求：第一个在服务器上进行大量计算（或者可能从数据库检索大量数据），第二个是立即返回结果的小请求。如果我们发出第一个请求，我们不会立即收到结果，而是会超时，超时后我们发出第二个小请求，然后示例中的 abortFlag 将为 true，因此我们可以检索结果第二个请求的结果，而且我们还可以检索之前超时的第一个请求的结果（因为第一次调用的 AsyncCallback 对象没有被销毁）。
因此，我们需要在超时发生后取消第一个 rpc 调用。我该怎么做？
In this example there is a pretty description of how to make a timeout logic using a Timer#schedule. But there is a pitfall there. We have 2 rpc requests: first makes a lot of computation on server(or maybe retrieving a large amount of data from database) and second a tiny request that returns results immediately. If we make first request, we will not recieve results immediately, instead we will have a timeout and after timeout we make the second tiny request and then abortFlag from example will be true, so we can retrieve the results of second request, but also we can retrieve the results of first request that was timed out before(because the AsyncCallback object of first call was not destroyed).
So we need some kind of cancelling the first rpc call after timeout occurs. how can I do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
让我给你打个比方。
您，老板，打电话给供应商，以获取一些产品信息。供应商说他们需要给您回电，因为收集信息需要一些时间。所以，你给了他们你的工头的联系方式。
您的工头正在等待电话。然后，您告诉领班，如果需要的时间超过 30 分钟，请取消信息请求。
你的工头认为你疯了，因为他无法取消请求，因为他没有一个帐户可以让他有权访问供应商的订购系统。
因此，您的领班在 30 分钟后就会忽略供应商的任何回复。你聪明的工头在他的手机中设置了一个定时器，30 分钟后就会忽略供应商的电话。即使你杀死了你的工头，切断了所有的通讯联系，供应商仍然会忙着满足你的要求。
GWT 客户端上没有任何可以取消的内容。回调只是一个等待被调用的 JavaScript 对象。
要取消调用，您需要告诉服务器端停止浪费 cpu 资源（如果这是您关心的问题）。您的服务器端必须编程为提供一个服务 API，调用该 API 时将取消作业并立即返回以触发您的 GWT 回调。
您可以刷新页面，这将丢弃页面请求并关闭套接字，但服务器端仍将运行。当服务器端完成其任务并尝试执行 http 响应时，它会失败，并在服务器日志中显示它已丢失客户端套接字。
这是一个非常直接的推理。
因此，如何通过后续请求来识别先前的请求，这取决于您的 servlet/服务的设计。
级联回调
如果请求 2 依赖于请求 1 的状态，则应执行级联回调。如果请求 2 要在成功时运行，则应将请求 2 放入回调的 onFailure 块中。而不是一个接一个地提交两个请求。
否则，你的计时器应该触发请求 2，而请求 2 将有两个职责：
Let me give you an analogy.
You, the boss, made a call to a supplier, to get some product info. Supplier say they need to call you back because the info would take some time to be gathered. So, you gave them the contact of your foreman.
Your foreman waits for the call. Then you told your foreman to cancel the info request if it takes more than 30 minutes.
Your foreman thinks you are bonkers because he cannot cancel the request, because he does not have an account that gives him privilege to access the supplier's ordering system.
So, your foreman simply ignores any response from the supplier after 30 minutes. Your ingenious foreman sets up a timer in his phone that ignores the call from the supplier after 30 minutes. Even if you killed your foreman, cut off all communication links, the vendor would still be busy servicing your request.
There is nothing on the GWT client-side to cancel. The callback is merely a javascript object waiting to be invoked.
To cancel the call, you need to tell the server-side to stop wasting cpu resources (if that is your concern). Your server-side must be programmed to provide a service API which when invoked would cancel the job and return immediately to trigger your GWT callback.
You can refresh the page, and that would discard the page request and close the socket, but the server side would still be running. And when the server side completes its tasks and tries to perform a http response, it would fail, saying in the server logs that it had lost the client socket.
It is a very straight forward piece of reasoning.
Therefore, it falls into the design of your servlet/service, how a previous request can be identified by a subsequent request.
Cascaded Callbacks
If request 2 is dependent on the status of request 1, you should perform a cascaded callback. If request 2 is to be run on success then, you should place request 2 into the onFailure block of the callback. Rather than submitting the two requests one after another.
Otherwise, your timer should trigger request 2, and request 2 would have two responsibilities: