3

简而言之，我们有时会看到少量 Cloud Bigtable 查询重复失败（连续 10 次甚至 100 次）并出现错误rpc error: code = 13 desc = "server closed the stream without sending trailers"，直到（通常）查询最终起作用。

具体来说，我们的设置如下：

我们正在 Google Compute Engine 上运行一组（<10 个）Go 服务。每个服务从一对 PULL 任务队列中租用任务。每个任务都包含一个 bigtable 行的 ID。任务处理程序执行以下查询：

row, err := tbl.ReadRow(ctx, <my-row-id>, 
    bigtable.RowFilter(bigtable.ChainFilters(
        bigtable.FamilyFilter(<my-column-family>),
        bigtable.LatestNFilter(1))))

如果查询失败，则任务处理程序简单地返回。由于我们租用了租用时间在 10 到 15 分钟之间的任务，稍后该任务的租用将到期，它将再次被租用，我们将重试。这些任务的最大重试次数为 1000 次，因此可以在很长一段时间内多次重试。在少数情况下，特定任务会因上述 grpc 错误而失败。该任务通常会在每次连续运行数小时或数天时失败并出现相同的错误，然后（看似出乎意料）最终成功（或任务用完重试并死亡）。

由于这通常需要很长时间，因此似乎与服务器负载无关。例如，现在在一个星期天早上，这些服务器的负载非常轻，但是当我跟踪日志时，我看到了很多这样的错误。从这个答案中，我最初认为这可能是由于试图查询大量数据，可能接近云大表支持的最大限制。但是我现在发现情况并非如此。我可以找到许多示例，其中多次失败的任务最终成功并报告仅检索到少量数据（例如<1 MB）。

我还应该在这里看什么？

编辑：通过进一步的测试，我现在知道这完全独立于机器（客户端）。ReadRow如果我在其中一台任务租赁机器上跟踪日志，等待“服务器关闭流而不发送预告片”错误，然后尝试从另一台不相关、完全未使用的机器对同一 rowId进行一次性查询，我得到重复同样的错误。

4

1 回答 1

2

此错误通常是由您的回复中包含超过 256MB 的数据引起的。

但是，目前我们的服务器端错误处理代码中存在一个错误，该错误允许HTTP/2预告片中的一些无效字符，这是规范不允许的。这意味着某些包含无效字符的错误消息将被视为此类错误。这应该在明年年初解决。

于 2015-12-15T02:42:10.570 回答