Page History

...

黑科技 udf 下仔细剖析：

再次复测一轮后，依然复现了此 bug，此刻心中是绝望的，然而多多少少也唤醒了我们心中的一丝好强之心。为此，我们仔细的过了一遍查询的代码，然而我们惊奇的发现，”单机不会出现并发问题而分布式会在此处出现并发问题“的结论并不正确，这里在分布式中既然是串行的，由此可见。大家的印象依然是不太靠谱的，即使是自己实现的代码，过了很久也可能会忘掉。既然如此，那上个修复显然是没有意义的。bug，此刻心中是绝望的，然而多多少少也唤醒了我们心中的一丝好强之心。为此，我们仔细的过了一遍查询的代码，然而我们惊奇的发现，”单机不会出现并发问题而分布式会在此处出现并发问题“的结论并不正确，这里在分布式中依然是串行的，由此可见。大家的印象依然是不太靠谱的，即使是自己实现的代码，过了很久也可能会忘掉。既然如此，那上个修复显然是没有意义的。

此刻能做什么的？只能耐心的回到本质来分析。我们首先利用黑科技 udf 来打出了 FileReaderManager 的 closedReferenceMap。可以看到，这些文件刚好是没有继续合并的文件，其都存在读引用尚未释放。在分布式查询的实现中，每个查询在协调者节点生成一个 queryId，这些 queryId 在其他节点查询时为了避免冲突又会生成一个数据节点本地的 queryId 并保存到 context 中。所以 udf 打出来的这些 queryId 都是数据节点本地的 queryId，跟前面的 regist queryid 里面的 id 并不相等，虽然他们是一一对应的。但至少，在再次复测前我们无法找到这个对应关系。

...

在协调者节点来看，当我创建 remoteReader 的时候，如果返回 的时候，如果不返回 -1 我才会将这个节点注册到 context 的 remoteNodes 里面，之后 endquery 的时候便会向这个节点发送 ednquery 的 rpc。如果是 -1，那么便不会注册该节点，因为本来也没有数据，不需要去 endquery...哎？是这样吗？

...