Nifi：为什么不“通知”重置计数器，为什么“等待”计数不正确？

Question

我试图设置等待并通知流程以在多个复杂流程结束时执行最终流程。但是，我不明白为什么计数器不重置。

最重要的是，当计数器大于“ Target Signal Count”（目标信号计数）属性时，等待过程会将流文件发送到“成功”路径。

删除并创建新的缓存客户端和服务器会重置计数器，并且直到“通知”过程结束后我清空队列后问题才重新出现。

Answer 1

使用硬编码的释放信号标识符，等待处理器将仅将流文件传递给成功关系一次。也就是说，当信号计数器达到目标信号计数2时。当生成另一个流文件时，将使用相同的释放信号标识符。因此，通知处理器会将计数增加到2以上。

  

最重要的是，等待过程将流文件发送到“成功”   计数器大于“目标信号计数”属性时的路径。

不。当信号计数与您的目标信号计数完全匹配时，流文件将发送到成功关系。

您可以通过两种方式解决此问题。

首先，您可以使用动态释放信号标识符，该标识符在每次生成新流文件时都会更改。 GenerateFlowFile创建一个文件名属性，您可以使用它。这样，您将为每个新的流文件使用一个新的缓存键，从而为每个新的根流文件使用一个新的计数器。

第二，您可以使用PutDistributedMapCache手动更新计数器。

我创建了一个流程来测试第一个解决方案：

GenerateFlowFile包含一些简单的文本：

SplitText简单地拆分文本，从而导致每行一个流文件。然后，将原始流文件路由到“等待”处理器：

请注意，我使用${filename}设置了动态释放信号标识符。 ${fragment.count}由SplitText处理器提供，并保存该特定用例中的拆分或行的总数。现在，您必须使用Notify处理器来增加计数器：

一旦所有路由到Notify的行都将释放计数器名称为chunks的信号，并且Wait处理器会将原始流文件路由到成功关系。

PS：要深入研究“等待/通知”，您可以查看此博客文章：How to wait for all fragments to be processed, then do something?。