我们正在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/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/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种字体之外的一种时,会退回到其已知的字体。我尝试了一些方法来解决此问题,但到目前为止还没有运气。

我希望这可以帮助别人。

09-11 19:35