Apache FOP 1.0 多线程 - 打开的文件太多 err24 [英] Apache FOP 1.0 Multithreading - Too many open files err24
问题描述
我们使用 Apache FOP 将大量 XML 转换为 AFP 和 PDF.我们当前的负载是每次在 HP-UX 系统上运行大约 25k 个文件.我们总共有 8 个线程，用于以生产者-消费者的方式初始化和触发 FOP 转换.最近在转换过程中出现多次失败，在查找时，我们收到了一般的 FOP 错误，例如:
We use Apache FOP to convert a whole lot of XML's to AFP's and PDF's. Our current load would be around 25k files per run on a HP-UX system. We have 8 threads in total that are used to initialize and trigger the FOP conversion in a producer-consumer fashion. Recently there have been multiple failures during conversion and when looked up, we've received generic FOP errors like:
**ERROR,2460364,FOToPDF_Thread_11,FOP Exception, something.pdf,Failed to resolve font with embed-url './Fonts/arial.ttf'**
或者它的错误未能加载字体规格文件，尽管文件完好无损并具有正确的权限.生成了许多其他 PDF，因此这不是问题.
or its an error failing to load the font metrics file although the files are intact with the right permissions. Many other PDF's are generated so this can't be the problem.
我们也结束了:
**java.io.FileNotFoundException: /PDF/20130111130002/something.pdf (Too many open files (errno:24))**
从正在处理的日志和数量来看，这看起来像是 FOP 问题.我读过 FOP 过去曾在字体文件中遇到过这个问题.在某些情况下，Apache 多次打开每个字体文件并且没有关闭句柄，从而导致大量打开的文件.这应该是固定的，但如果它仍然存在，除了将其发布在 Apache 列表上之外，还有什么好的和快速的解决方案?
Judging by the logs and volume being processed, this looks like an FOP problem. I've read that FOP has had this issue in the past with the font files. There have been instances where Apache has opened each font file multiple times and not closed the handles resulting in a large number of open files. This was supposed to be fixed, but if it still persists, what would be a good and quick solution to this, apart from posting this on the Apache lists?
每个进程的打开文件描述符的 HP-UX maxfiles 限制是否可以增加到 2048 以上?那会有帮助吗?还有其他建议吗?
Can the HP-UX maxfiles limit for the open file descriptors per process be increased beyond 2048? Would that help? Any other suggestions?
推荐答案
Apache FOP 项目的相关问题是
The relevant issue on the Apache FOP project is
https://issues.apache.org/jira/browse/FOP-2189
正如我在那里评论的那样，我无法在 FOP 1.0 中识别任何打开的文件句柄.接受 InputStream 参数的 FontFileReader 的构造函数确实没有关闭它，但是调用者(创建流的人)正在关闭它，参见
As I commented there, I was not able to identify any open file handle in FOP 1.0. The constructor of FontFileReader that takes an InputStream argument is indeed not closing it, but the caller (who created the stream) is closing it, see lines 94-106 of
这篇关于Apache FOP 1.0 多线程 - 打开的文件太多 err24的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
