这里批处理地理编码处于接受状态

Question

使用HERE批处理地理编码REST API，我已经提交了一个使用action=run参数对4个地址进行地理编码的作业，并在响应中返回了RequestId。通过以下URL访问API端点以获取作业状态时...

https://batch.geocoder.api.here.com/6.2/jobs/[RequestId]?action=status&app_id=[app_id]&app_code=[app_code]

...我收到以下答复：

<ns2:SearchBatch xmlns:ns2="http://www.navteq.com/lbsp/Search-Batch/1">
  <Response>
    <MetaInfo>
      <RequestId>[RequestId]</RequestId>
    </MetaInfo>
    <Status>accepted</Status>
    <TotalCount>0</TotalCount>
    <ValidCount>0</ValidCount>
    <InvalidCount>0</InvalidCount>
    <ProcessedCount>0</ProcessedCount>
    <PendingCount>0</PendingCount>
    <SuccessCount>0</SuccessCount>
    <ErrorCount>0</ErrorCount>
  </Response>
</ns2:SearchBatch>

SO上有another question存在同样的问题，ckHERE的回答中对此进行了解决：

  

状态为“已接受”表示您的工作已排队并且正在等待   执行插槽。我们在这里正在监控要排队的人   确保根据需要调整容量。

     

所以我想您的应用程序还可以，并且瓶颈可能是   在我们这边。

令人烦恼的是与此问题相关的其他一些答案，特别是工作最终需要多长时间才能完成。 For example：

  

看起来这是一个队列问题，除了我的一直在   近一个星期。这里的API从不运行批处理作业，始终返回已接受   状态

     

* 4天后*

     

这是一个队列问题。 ...所有工作突然间   同时完成。从那时起，服务一直运转良好。

哪个会引起我的疑问：

1. 我应该假设我的问题现在就在这里，还是在创建工作时仍然做错了什么（以及如何找到答案）？

2. 如果问题确实在这里结束，这种情况多久发生一次？一般来说，这里的服务是否可靠，周末是否会打h，或者我能否期望几天（几周）的定期工作会长时间延迟？

3. 这里是否有一个状态页面，我可以在其中检查其任何服务是否有问题？

Answer 1

请在项目符号下方找到问题的答案。

1. 我应该假设我的问题现在就在这里了吗，还是在创建工作时我仍然会做错什么（以及如何找出来）？ 是的，问题是由于一些不良的作业被提交并阻止了所有其他作业，因为它们不得不等待已经运行的作业。
2. 如果问题确实在这里解决，那么这种情况多久发生一次？这里通常是否相当可靠，并且本周末只是在打扰他们的服务，还是我可以期望几天（几周？）的工作定期出现长时间的延迟？ 这种情况不应该经常发生，因为我们已经进行了基本的检查，并不断改进检查以免出现此类问题
3. 这里是否有一个状态页面，我可以在其中检查他们的任何服务是否有问题？ 不幸的是，没有。我们不提供外部仪表板来查看服务或正在运行的作业

希望您发现它们有用。