java-Docker容器阻止中的Apache Batik转码器

我们正在docker容器中运行Spring应用程序.我们的应用程序可以提取SVG文件并将其转换为PDF格式,以嵌入到PDF中.

该应用程序可以在osx上正常工作并按预期进行转码.但是,当从具有不同文件系统的docker容器中运行时,转码器被卡住,并在某些奇异的递归文件搜索循环中使cpu崩溃.

java.lang.Thread.State: RUNNABLE
    at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
    at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
    at java.io.File.isFile(File.java:882)
    at org.apache.commons.io.filefilter.FileFileFilter.accept(FileFileFilter.java:59)
    at org.apache.commons.io.filefilter.AndFileFilter.accept(AndFileFilter.java:122)
    at org.apache.commons.io.filefilter.AndFileFilter.accept(AndFileFilter.java:122)
    at org.apache.commons.io.filefilter.OrFileFilter.accept(OrFileFilter.java:118)
    at java.io.File.listFiles(File.java:1291)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:357)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
    at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364

这是运行PDFTranscoder的线程的堆栈跟踪记录.递归调用Walk一段时间,然后最终调用getBooleanAttributes0,并且一切都阻塞.

经过一些进一步的研究,我们发现我们可以仔细查看strace命令的情况,并发现系统实质上是在无休止的循环中发送垃圾邮件.

stat(“ /./ sys / devices / pci0000：00 / PNP0103：00 / subsystem / devices / PNP0103：00 / subsystem / devices / PNP0103：00 / subsystem / devices / PNP0103：00 / subsystem / devices / PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 /子系统/设备/ PNP0103：00 / subsystem / devices / pcspkr / input / input1 / subsystem / input0 / subsystem / input0 / uniq“,{st_mode = S_IFREG | 0444,st_size = 4096,…})= 0< 0.000224>

我们似乎被封锁或挂在stat通话中.但是我们现在已经对系统调用进行了深入的研究,以至于很难调试.有人有什么想法吗？

解决方法:

我遇到了同样的错误.在尝试了许多修复后,我得出的结论是,这是您在Mac OS X上拥有可用字体的问题,而您的(无头)Docker容器OS没有字体.在各处搜索字体时,代码转换器不会出现故障.我通过将代码转换器强制为use the default fonts(并且不自动寻找其他字体)来解决了这一问题：

...
PDFTranscoder transcoder = new PDFTranscoder();
transcoder.addTranscodingHint(PDFTranscoder.KEY_AUTO_FONTS, false);
...
transcoder.transcode(transcoderInput, transcoderOutput);
...

请注意,这当然有一个缺点,当它遇到14种字体之外的一种时,会退回到其已知的字体.我尝试了一些方法来解决此问题,但到目前为止还没有运气.

我希望这可以帮助别人.

标签：apache-fop,docker,svg,batik,java
来源： https://codeday.me/bug/20191110/2014483.html