Java GAE为任务队列数据存储调用获取大量CancellationException

我有一个运行TaskQueue作业的JavaGAE实例。在过去的48小时里，我收到了很多CancellationException错误（24小时内大约36个）

该错误总是发生在对特定表的数据存储查询中。查询位于索引列projectId上，查询是复合OR（即projectId=-1或projectId=23）。整个表有96条记录，任何一个查询最多只能收回20条记录

有人知道我为什么会遇到这些问题吗

谢谢 保罗

更新：对不起，我的错误，这不是任务队列调用的一部分，而是设置任务队列调用的代码。通话时间平均约为59.5秒（感谢Alex指出这一点）。查看跟踪（感谢Alex），延迟似乎出现在数据存储调用中。它可以快到21ms或超过59000ms，这是很长的一段时间。我刚刚再次检查了日志，在过去24小时内没有出现任何异常，因此这可能是48小时内出现的小故障。

基于这个问题，听起来像是

CancellationException

意味着任务队列作业必须完成执行的10分钟超时

您的日志是否显示这些请求在抛出异常之前运行了多长时间（例如，stackdriver显示此延迟任务运行了902ms）

查询一个包含96条记录的表应该可以，但是如果不能够看到任务的代码是什么样子，就很难确定

您可以将任务拆分为更小的“子任务”，并让子任务在返回之前启动下一个子任务

编辑：您也可以尝试到这里查看您的请求花费时间的详细情况

---

Hi，它没有显示它为put运行了多长时间。这个查询就在代码的开头附近。我不能拆分它，因为这个查询是用来决定需要发生什么的。这就好像故障在数据存储中，它正在冻结，但我看不到这些方面的任何东西。我添加了2个屏幕截图。请求的总运行时间显示了什么？还有，你在跟踪报告中看到了什么？Shi Alex，谢谢你提供的额外信息，这真的很有帮助（我以前从来没有注意过，也不知道跟踪屏幕）。请参阅上面的更新。所以听起来好像它只是挂起，然后达到60秒超时。这篇文章讨论了它，并提供了一些提示（特别是关于热身请求的部分）：很难说为什么它会挂起，可能有多种原因。我以前也遇到过GAE的其他问题，一些较低级别库中的内存泄漏会导致实例上运行的所有请求挂起，直到它们超时。嗨，Alex，是的，这听起来有点像一个一次性（或48次）的问题。也许，如果它可能是内存泄漏，我会尝试重新部署，看看是否修复。我希望有一些简单的方法来重置系统以克服这些问题。谢谢你的洞察力和帮助