Docker Container Blocking内のApache Batik Transcoder

Question

ドッキング・コンテナ内でSpringアプリケーションを実行しています。私たちのアプリケーションでは、SVGファイルをPDF形式に変換してPDF内に埋め込むことができます。

アプリケーションはosxで正しく動作し、期待どおりにトランスコードされます。しかし、異なるファイルシステムを持つドッカーコンテナの内部から実行すると、トランスコーダが突っ込んだり、いくつかの奇妙な再帰的なファイル検索ループで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コマンドで何が起きているのかを詳しく調べることができ、システムが本質的に無限ループで次のようなスパムを引き起こしていることがわかりました。 PNP0103：00/subsystem/devices/PNP0103：00/subsystem/devices/

stat（ "/./ sys/devices/pci0000：00/PNP0103：00/subsystem/devices/PNP0103：00/PNP0103：00/subsystem/devices/PNP0103：00/subsystem/devices/PNP0103：00/subsystem/devices/PNP0103：00/subsystem/devices/PNP0103：00/subsystem/devices/PNP0103：00/00 /サブシステム/デバイス/ PNP0103：00 /サブシステム/デバイス/ PNP0103：00 /サブシステム/デバイス/ PNP0103：00 /サブシステム/デバイス/ PNP0103：00 /サブシステム/デバイス/ PNP0103：00 /サブシステム/デバイス/ PNP0103：00/（st_mode = S_IFREG | 0444、st_size = 4096、...}）= 0 < 0.000224>サブシステム/デバイス/ PNP0103：00/subsystem/devices/pcspkr/input/input1/subsystem/input0/subsystem/input0/uniq "

statコールでブロックされているか、ハングしているようです。しかし、我々はデバッグするのが難しいことが判明したので、システムコールについて深く掘り下げた。誰にもアイデアはありますか？

Answer 1

私のプロジェクトでは同じ問題がありました。バティックから1.7バージョンへのダウングレードで解決します。

私はこれがうまくいくと思います。

Answer 2

パラメータ '-Duser.dir = /％CATALINA_HOME /'をCATALINA_OPTSに追加してみてください。私は私のcentosサーバーで同じ問題が発生しました。

Answer 3

同じ問題がありました。 DockerFileでWORKDIR変数を設定して解決しました。 私はspring jarファイルをコピーする私の展開ディレクトリに設定しました。 すなわち

WORKDIR ${DEPLOYMENT_DIR} 

ポンポンで最新のバティックライブラリを使用して

<dependency> 
     <groupId>org.apache.xmlgraphics</groupId> 
     <artifactId>batik-all</artifactId> 
     <version>1.9.1</version> 
    </dependency> 
    <dependency> 
     <groupId>org.apache.xmlgraphics</groupId> 
     <artifactId>fop</artifactId> 
     <version>2.2</version> 
    </dependency>