我们有两个cron作业，它们遇到两个不同的动态后端，两者都遇到了同样的问题。我可以通过导航到cron作业直接在浏览器中执行的URL来复制问题。
我们的应用程序具有相当高的冷启动时间。当我导航到使用后端的URL时，我看到以下错误
Error: Server Error
The service you requested is not available yet.
Please try again in 30 seconds.
在日志中，我看到后端的/ _ah / start请求（我们没有特定的处理程序），并显示以下消息：
This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application.
然后我做的是刷新后端网址，它工作正常。
所以我的理论是，如果后端已经加载，那么cron作业就能正常工作。如果不是，它不会等待足够长的时间来查看后端是否会加载。
假设这是正确的，有没有办法让cron作业等到/ _ah / start完成？
另外两个选项是使用我们宁愿不做的驻留实例，或者改善我们在待办事项列表上的冷启动时间，但直到现在我们还没有成为问题（我们使用驻留实例）为了前端）。
后端是B1。假设我们可以再次升级，但是再次成为现金短缺的创业公司，我宁愿不这样做。
答案 0 :(得分：3)
Cron没有taskqueue所具有的重试功能，因此我建议使用前端cron将任务放到具有动态后端实例的任务队列中。这样，cron请求本身将由一个空的前端实例处理，这个实例比你现在正在做的更可靠，并且你的后端任务执行将在失败时重试。
为了制作第一个cron调用robuster，你可以为一个特定的后端任务多次发出cron请求，并在执行任务时，命名一个与特定任务相关的任务（例如20120430-task1或其他），catch任务复制的错误（除了记录之外，在catch子句中什么也不做）。
有关命名任务的更多详细信息，请参阅： https://developers.google.com/appengine/docs/java/taskqueue/overview#Task_Names
答案 1 :(得分：0)
我用来确保后端在线并准备就绪的一个方便的技巧是在你的工作cron前30秒安排一个无操作的cron。如果无操作请求失败或成功并不重要，它会在您的重要cron之前为您的后端预热。
关于错误代码503的另一个注释 - 如果您处理不存在的后端实例编号，有时会发生这种情况。检查任务标头以确保后端主机是0.yourbackend.yourapp.appspot.com，或者＃is＆lt;总分配后端。