Apache Camel ZipInputStream 通过并行处理关闭答案

【问题标题】：Apache Camel ZipInputStream closed with parallel processingApache Camel ZipInputStream 通过并行处理关闭
【发布时间】：2014-06-02 17:09:04
【问题描述】：

我成功地使用ZipSplitter() 处理压缩文件中的文件。如果可能，我想使用并行处理，但调用 parallelProcessing() 会导致流过早关闭。当流被DefaultStreamCachingStrategy 缓存时，这会导致IOException。

我注意到当启用并行处理时，ZipIterator#checkNullAnswer(Message) 被调用，这会关闭ZipInputStream。奇怪的是，如果我在调试器中徘徊在这个方法上，一切都是花花公子，这表明迭代器在处理完成之前就被关闭了。这是一个错误还是我搞砸了什么？

表现出这种行为的我的路线的简化版本是：

from("file:myDirectory").
    split(new ZipSplitter()).streaming().parallelProcessing().
        log("Validating filename ${file:name}").
    end();

这是使用 Camel 2.13.1。

【问题讨论】：

【解决方案1】：

您可以尝试将CAMEL-7415 应用到camel 2.13.1 分支吗？
我不确定它是否可以解决您的问题，但值得一试。

【讨论】：

谢谢威廉；赞赏。看起来该补丁已经在 2.13.1 中，除非我遗漏了一些东西（如果结果是迭代器，肯定会检查仅在 UnmarshallProcessor 中调用 IOHelper.close()）。
看起来正在发生的事情是 ZipIterator 在处理完 zip 中的最终条目后立即关闭流，而不是等待任何并行任务完成。我会看看我是否可以暂时实施一个肮脏的黑客......
实际上，使用 zip 文件进行并行处理似乎存在更广泛的问题 - 使用它使用验证器组件执行并行处理（我的 zip 文件包含 XML 文件）导致“文件提前结束”SAX例外。
关于 SAX（好吧，空的 InputStream）问题，如果我用我的调试器在 ZipIterator.getNextElement() 上徘徊，一切都很好。这与我最初的问题相同。
在拆分工作完成后，如果不引入某种回调来关闭流，解决此问题并不容易。我认为你可以填写一个 CAMEL JIRA 来让我们记住这个问题。