PDF を画像に変換するために、Ghost4J ネイティブ ライブラリの 32 ビットおよび 64 ビット dll ファイルを使用しています。ThreadPoolExecutor、つまりマルチスレッドで使用する必要がありますが、ネイティブであるため、JBoss が頻繁にクラッシュします。
このライブラリの使用を同期した後、スレッドがうまく機能しません。つまり、4 スレッドでも 8 スレッドでも、パフォーマンスに違いはありません。
これを行う安全な方法はありますか?
PDF を画像に変換するために、Ghost4J ネイティブ ライブラリの 32 ビットおよび 64 ビット dll ファイルを使用しています。ThreadPoolExecutor、つまりマルチスレッドで使用する必要がありますが、ネイティブであるため、JBoss が頻繁にクラッシュします。
このライブラリの使用を同期した後、スレッドがうまく機能しません。つまり、4 スレッドでも 8 スレッドでも、パフォーマンスに違いはありません。
これを行う安全な方法はありますか?
Ghost4jの人々がマルチスレッドに推奨するものを試しましたか:
マルチスレッド
Ghostscript がスレッドセーフであることを確認することが最初のステップです。しかし、Ghost4J がマルチスレッド / マルチユーザー環境 (たとえば Web アプリケーション) で使用される場合はどうなるでしょうか?
Ghost4J を使用してドキュメント変換 Web アプリケーションを作成する場合、ユーザーが前のユーザー要求が完了するまで待たなければならない場合、単一の Ghostscript インタープリターを使用することは実際の問題になる可能性があります。
この制限を克服するために、Ghost4J は高レベルの API コンポーネントでマルチスレッドのサポートを提供します (バージョン 0.4.0 以降)。
それはどのように可能ですか?: コンポーネントの処理は異なる JVM で行われます。
メイン JVM のコンポーネントは、他の JVM (他のシステム プロセスで実行中) を起動し、cajo ライブラリ (ghost4j JAR ファイルに組み込まれている) を使用してそれらを制御できます。
メイン JVM からスレーブ JVM を作成できることを確認するには、java コマンドを使用して、コマンド ラインから Java を起動できるかどうかを確認します。
マルチスレッドの動作は、コンポーネントに maxProcessCount プロパティを設定することで制御できます (利用可能な場合)。
= 0 の場合: マルチスレッドは無効です。コンポーネントは、処理を開始する前に、Ghostscript インタープリターが解放されるまで待機する必要があります。
> 0 の場合: マルチスレッドが有効になります。コンポーネントの処理はメイン JVM ではなく、スレーブ JVM で行われます。maxProcessCount に指定された値は、コンポーネントに対して同時に実行できるスレーブ JVM の数を示します。スレーブ JVM の最大数に達すると、新しい処理要求は別の処理が完了するまで待機します。
以下は、2 つのスレーブ JVM によるマルチスレッドを可能にするために PDFConverter コンポーネントをセットアップする方法です。
//create converter
PDFConverter converter = new PDFConverter();
//set multi-threading
converter.setMaxProcessCount(2);