トラブルシューティング:問題

トラブルシューティング:解決策

自分のプログラムが期待するほど速く動きません。

一般的に、アプリケーションは Wrapper の環境下であっても、スタンドアローンの状態と同等の速度で動くはずです。 いくつかチェック項目があります。

コンソール出力

Windows を含め、一部のプラットフォームにおいて、大量のテキストを System.out 或いは System.errへ送ることは、 プログラムをスローダウンする原因となります。 その理由は、グラフィカルの GUI 環境では、全出力がスクリーンにレンダリング(映写)されているためだからです。 結果としては同じなのですが、これは Wrapper やアプリケーションに問題があるのではなく、 むしろ CPU を消費している OS に起因しています。

この負荷影響を十分に軽減するためには、stdout(データ標準出力)ではなく、 ファイルへの出力をするログツールを使うことです。 そうすることにより、出力が Wrapper やユーザーコンソールへ送信されることがなくなり、負荷が軽減されます。

おススメの他の選択肢としては、[wrapper.console.loglevel]プロパティで、 Wrapper コンソールの出力レベルを、Wrapper のログファイルだけに出力するように設定することです。 Windows サービスとして動かすときにコンソールが有効になっていない場合、コンソール出力は、デフォルトで無効になります。

メモリ

ご利用のマシンに、ディスクスワッピング(ハードディスクを代用した一時的な仮想メモリ)ではなく、 JVM を動かすための十分な物理メモリがあることを確認してください。 Java はガベージコレクション機能を持ち、Java がメモリを管理しているため、 大容量のメモリをページングするように、 Java が強制しているため、著しいスピードの打撃を受けるのが一般的です。

Oracle 社のドキュメンテーション

参照する意義のあるドキュメントとしては、Oracle 社のサイトです: 『Java HotSpot VM におけるパフォーマンスについて(英語)』 加えて、 『 ガベージコレクション』の問題について語るとても有益な JDC Tech Tip(英語)』もあります。 Oracle 社の上記の日本語ページはありませんが、日本語の説明ページは『JavaTM 仮想マシン』 や 『 Java HotSpotTM Client Virtual Machine および Java HotSpotTM Server Virtual Machine』もありますのでご参考にご覧ください。

Wrapper がネイティブライブラリをロード(読み込み)できないという警告が出ています。

数名のユーザーから、「wrapper.log 」ファイルに 以下のようなメッセージが表示されるという報告をいただきました:

WrapperManager: ERROR - Unable to load the Wrapper's native library because none of the
WrapperManager:         following files:
WrapperManager:           wrapper-windows-x86-64.dll
WrapperManager:           wrapper.dll
WrapperManager:         could be located on the following java.library.path:
WrapperManager:           E:\myworkspace\tortoise\wrapper\wrapper_3.5.x\professional\bin\..\lib
WrapperManager:         Please see the documentation for the wrapper.java.library.path
WrapperManager:         configuration property.
このメッセージは、Wrapper の Java コンポーネントが初期化中にネイティブライブラリを ロード(読み込み)できていないために表示されます。 ご利用中の「wrapper.conf」ファイルには、 [wrapper.java.library.path]プロパティが入っています。 このプロパティは、Wrapper がネイティブライブラリ (Windows:wrapper.dll、Linux/UNIX:libwrapper.so)を探しにいくディレクトリーを指定しています。 指定したディレクトリーにライブラリファイルを配置するか、 あるいは、ライブラリが置かれているディレクトリーを、そのプロパティに設定するべきです。

デルタパックをご利用の場合、プラットフォームに対応するライブラリが指定されたディレクトリにあることを確認してください。

アプリケーションがスタートしません。問題を絞るには、どうすればいいですか。

問題の詳細がコンソールに表示され、 同様にログファイルにも出力されているはずです。 さらに詳しい出力を得るためには、 ご利用中の「wrapper.conf」ファイルを編集して、[wrapper.debug]プロパティを有効化(コメント記号を外す)して、デバッグを有効にしてください。 これで、アプリケーションを監視して、起動プロセスの各ステップごとに出力の詳細が表示されます。

もしアプリケーションが、Wrapper を使わない状態なら動作し、Wrapper を使うと動作しなくなる場合には、 往々にして、「wrapper.conf」ファイルの設定に誤りがあることが多いです。 Java を起動するコマンドをもう一度じっくり確認して、デバッグ出力を調べてください。 クラスパス等の設定に誤りがある可能性があります。

自分で設定したログファイルにログが出力されません。

Wrapper が指定された Wrapper コンフィギュレーションファイルを見つけられないか、 何かの理由により、構成されたログファイルを開くことができない可能性があります。 どちらのケースでも Wrapper は、ログファイル「wrapper.log」を現在の作業ディレクトリ(カレントディレクトリ)へ出力します。 カレントディレクトリは、ほとんどの場合、 バイナリが含まれているディレクトリです。 ただし、いくつかのケースでは、Windows サービスとして実行しているとき、 「wrapper.log」ファイルは、 システムディレクトリ(WinNT\System32)に出力される場合もあります。

アプリケーションがシャットダウン時にハングアップします。

アプリケーション内で[System.exit()]を呼び出すと、 Wrapper はそれを検知して、キレイなシャットダウンを試みます。 もし、シャットダウンプロセス中に、 アプリケーションが再び[System.exit()]を呼び出すと、 そのコールが永久にブロックしてしまい、アプリケーションがハングアップします。 また、AWT フレーム上で、あるいは、シャットダウンフックスレッド内部からのウィンドウ上で、 [destroy()]メソッドを呼び出すと問題が起きます。 この問題を回避する方法の詳細については、 コンフィギュレーション概要にある [wrapper.disable_shutdown_hook]プロパティを参照してください。

スレッドダンプ後のシャットダウン時に JVM がハングアップします。

この問題は、[wrapper.java.command]プロパティを、直接「java.exe」へではなく、 バッチファルへ設定していることが原因かもしれません。 スレッドダンプを要求すると、「BREAK」シグナルが Java プロセスではなく[command.exe/shell]プロセスへ送信されます。 それで、シグナルを JVM へ転送しますが、同時に、『[CTRL]+[C]のキー操作があった』という内部フラグが設定されます。 バッチスクリプトチャイルド(子)が終了するとき、 即座にユーザーに「そのバッチスクリプトを継続したいか、あるいは停止したいか」と尋ねます。

INFO   | jvm 1    | 2009/10/23 14:30:35 | WrapperManager デバッグ: パケット送信しました STOPPED : 0
INFO   | jvm 1    | 2009/10/23 14:30:36 | Terminate batch job (Y/N)?
ERROR  | wrapper  | 2009/10/23 14:30:56 | シャットダウン失敗: 終了する JVM 待ちのタイムアウト。
ERROR  | wrapper  | 2009/10/23 14:30:56 | JVM はリクエストに応じて終了しませんでした、中止しました
STATUS | wrapper  | 2009/10/23 14:30:57 | <-- Wrapper が停止しました

もし JVM 起動の前/後に、何か追加プロセスをする必要があるならば、 Java Service Wrapper プロフェッショナル版のイベントコマンド(イベントに応じたコマンド実行)設定機能をご利用ください。

API コール WrapperManager.requestThreadDump (Error 0x57) を利用できません。

この問題は、前述の問題と同類であり、同じ理由により引き起こされています。

INFO   | jvm 1    | 2009/10/23 14:35:48 |  WrapperJNI Error: Unable to send BREAK event to JVM process: The parameter is incorrect. (0x57)

もし JVM 起動の前/後に、何か追加プロセスをする必要があるならば、 Java Service Wrapper プロフェッショナル版のイベントコマンド(イベントに応じたコマンド実行)設定機能をご利用ください。

Wrapper で動作させるとスタートアップ時に、JBoss 6.* で複数のエラー「ERROR: Error installing to...」が出力されます。

INFO   | jvm 1    | 2011/01/06 17:23:05 | ERROR: Error installing to Configured: name=ServiceBindingManager state=Configured
INFO   | jvm 1    | 2011/01/06 17:23:05 | java.lang.Exception: Error calling callback JMXRegistrationAdvice for target context ServiceBindingManager
...

JBoss バージョン 6 では、org.jboss.system.server.jmx.MBeanServerBuilderImpl をベースにした MBeanServer Factory を内部的に利用していますが、 これは、デフォルトの JVM MBeanServerBuilder(javax.management.MBeanServerBuilder)と互換性がありません

この解決には2つの手法があります。 まず最初の手法は、Wrapper の MBeans を登録から外して無効にすることです。 詳しくは、インテグレーション方法1をご覧ください。 もう一つの手法は、JBoss が使っている MBeanServer Factory を、JVM でも使うようにすることです。 詳しくは、JMX ページをご覧ください。

Wrapper が開始時に署名に関するエラー報告/警告レポートを送ってきます。

wrapper  | 「C:\wrapper-windows-x86-32-3.5.7-pro\bin\wrapper.exe」に署名が見つかりましたが、一致しません: (エラーコード: 0x800b010a)
A certificate chain could not be built to a trusted root authority. (0x800b010a)
wrapper  |   署名者証明: 
wrapper  |     シリアル番号: 
wrapper  |       00 97 06 fe b5 6e 56 cc cb 66 3a bb 55 a7 a0 e4 76 
wrapper  |     発行者名: UTN-USERFirst-Object
wrapper  |     件名: Tanuki Software Ltd.
wrapper  |   タイムスタンプ証明:
wrapper  |     シリアル番号: 
wrapper  |       47 8a 8e fb 59 e1 d8 3f 0c e1 42 d2 a2 87 07 be 
wrapper  |     発行者名: UTN-USERFirst-Object
wrapper  |     件名: COMODO Time Stamping Signer
wrapper  |     タイムスタンプ日時 : 2010/12/19 22:32
wrapper  | Wrapper 停止します。

Wrapper バージョン 3.5.7 から、 Wrapper 全エディション(コミュニティー版、スタンダード版、プロフェッショナル版)の Windows バイナリ (例えば「wrapper.exewrapperW.exe、あるいは wrapper.dll」)には、 弊社タヌキソフトウェアからの純正ファイルであるか認証するコード署名が導入されています。 何か問題を検知すると、Wrapper はシャットダウンされます。

Wrapper バージョン 3.5.28 から、Wrapper は SHA-2 証明書で証明され、これまで使用されていた SHA-1 アルゴリズムよりも強力なセキュリティを提供します。 これは、2016年1月1日以降 SHA-1 のサポートを終了すると公開しましたマイクロソフトの SHA-1 廃止措置に関するポリシーに伴い変更することを決めました。

弊社の署名者 Comodo によって提供された証明書が正しくインストールされていない場合、上記のエラーが発生します。

証明書は Wrapper を作動しているアカウントがアクセスできるストアにインストールされる必要があります。 Wrapper はコンソールアプリケーションとして作動している場合、それは現在のユーザーの可能性があります。 サービスとして動かしている場合、利用しているサービスアカウントからアクセス可能である必要があります。 その代替案は、両方のモードでアクセスできるように証明書をローカルマシンにインストールすることです。

インストールされた証明書は Windows 証明書マネージャー 「certmgr.msc」(現在のユーザー)、 あるいは 「mmc」(全てのユーザー)から調べることができます。

特定のアカウントの証明書を管理するには Windows の検索ボックスから「mmc」を実行してください。 ファイルメニュで、「スナップインの追加と削除」をクリックし、「証明書」をダブルクリックしてください。 そこで「ユーザー アカウント」、「サービス アカウント」、若しくは「コンピューター アカウント」を管理する証明書を選択します。 サービスアカウントの場合、コンピューターにインストールされているすべてのサービスが表示されます。 Wrapper をサービスとしてインストールした際に使用したサービスを選択してください。

二つの証明書をインストールできます。下記に Comodo ウェブサイトより証明書をダウンロードできる URL があります。

カレント(現在の)ユーザーまたはローカルコンピュータの証明書をインストールするには単に「.crt」ファイルを実行し、 インストール手順に従います。 サービスユーザーへインポートするには、「mmc」を実行し、上記と同様にスナップインを追加し、 左パネルにあるこのスナップイン配下の一つの任意のストアを選択し(フォルダーアイコンでマークされています)、 メニューの[操作]→[すべてのタスク]→[インポート]をクリックし、 [証明書の種類に基づいて、自動的に証明書ストアを選択する]オプションを選択してください。

それでもエラーが表示される場合は、サーバーのローカルセキュリティポリシーが厳しすぎて、証明書を検証できない可能性があります。 こちらの設定はサーバーのローカルセキュリティポリシーにあります。 Windows の実行/検索ボックスから「secpol.msc」を起動させ、[公開キーのポリシー]直下にある、[証明書パス検証の設定]をクリックします。 ポリシー設定が定義されている場合、[ストア]タブにある、「ルート証明書ストア」の[サードパーティのルート CA とエンタープライズのルート CA]にチェックが入っていることを確認してください。 これが有効にならない/できない場合、別の選択肢は「サードパーティのルート CA」フォルダーから、「UTN-USERFirst-Object Certificate」「信頼されたルート証明機関」フォルダーへ移動させることです。

Wrapper バージョン 3.5.8 では、 カウンター署名者(副署名)の問題によるものではなく、原因は直接 Wrapper によって署名が認証できない場合にのみ Wrapper がシャットダウンします。

Wrapper バージョン 3.5.7 では、潜在的なバグがあり、 署名認証に失敗して、 Wrapper がエラー報告を送ろうとすると、アクセス違反を引き起こしていました。

Wrapper バージョン 3.5.34 から、Wrapper バイナリーは「SHA-1」および「SHA-2」ハッシュアルゴリズムで二重に署名されているため OS レベルでより強力な検証を可能にしました。 アルゴリズムとタイムスタンプを確認するのは、バイナリを右クリックし、コンテキストメニューの「プロパティ」を選択して、 「デジタル署名」タブを開いてください。

「SHA-256」ハッシュアルゴリズムは、このアルゴリズムをサポートしていない古いバージョンの Windows では表示されません。 マイクロソフト社は Windows 7 および Windows Server 2008 R2 用に「SHA-2」のサポートを追加するアップデートを公開しました。 このアップグレードが存在している場合、「SHA-2」ハッシュを検証できますが、存在しない場合は、「SHA-1」ハッシュのみを 検証することができます。 最新の Windows バージョンは「SHA-256」をサポートしているため、この更新は不要ですが、古いバージョン(Windows XP、Vista、Windows Server 2008)では「SHA-1」ハッシュのみを検証できます。

デジタル署名が有効であることを確認するには、署名リストでその署名をクリックします。

最後に、Windows XP SP2 以前や Windows Server 2003 では「SHA-2」がサポートされておらず、 新しい証明書はこれらのプラットフォームに適用されないことに注意してください。 Windows Itanium 用のバイナリも署名されなくなります。

Wrapper は何故外部 Comodo サーバーにアクセスしようとしていますか。

Wrapper 自体は Comodo や他のサーバーにアクセスはしませんが、Wrapper バージョン 3.5.7 より、バイナリは Comodo 証明書でコードサイニングされています。 これは、OS が Wrapper バイナリが実際にタヌキソフトウェアのものであること確認するために重要です。

Windows がコードサイニングされたバイナリを起動するときに、先にバイナリが改ざんされていないことを確認するために バイナリをチェックして署名と一致することを確認します。 通常、バイナリを確認する際に使用される Comodo 証明書は Windows マシン上に既存していますが、場合によって、 OS はインターネットへ接続し、知られた場所からダウンロードします。 Wrapper が起動している時に接続するように見えますが、実際には開始前に接続します。 場合によって、Wrapper が接続しているように見えます。 次のサーバーへのアクセスが報告されています: ocsp.comodoca.coma125-56.204-123.deploy.akamaitechnologies.com(Akamai サーバーの IP 部分はリクエストによって異なります。)

これはお客様へ懸念を引き起こす場合は、スタンダード版やプロフェッショナル版で Wrapper バイナリをカスタマイズ することで証明が削除されます。 ただし、そうすることで OS はバイナリの真正性を検証するが出来なくなります。

Windows 上で一定数のサービスしか実行できません。

Wrapper 自体では、Windows 上で動作できる Wrapper インスタンスの数に制限をかけていませんが、 Wrapper や特に Java は、様々なリソースを消費するため、事実上、そのシステム上での動作に限界があります。 問題を引き起こしそうな、最も一般的なリソースは、デスクトップヒープです。 対処方法など詳しくは、「デスクトップヒープ問題を解決する」をご覧ください。

引数を要する(モジュール指定時などに使用される) Java 9 の新しいオプションを指定するには?

Java 9 は複数の引数で指定されるオプション( --module-path や --add-modules など)を導入しました。 通常、引数はオプション名と空白スペースで区切られますが wrapper.java.additional.<n> プロパティの値に空白スペースが含まれている場合、区切り文字ではなく引数値の一部として解釈されます。 それの解決方法の一つとしてはオプション名と引数値空白スペースの代わりに等号「=」 で区切ることです。

wrapper.java.additional.1=--add-modules=MODULE1,MODULE2

これは、長いオプション(「--」で始まるオプション)でしか使用ができません。 同等の短いオプションで使用できません。 例えば、「-p=<PATH>」 は使用できません。(「-p」は「--module-path」の同等の短いオプション)。

空白スペースと同等の短いオプションの両方を利用できる別の方法とは、JDK_JAVA_OPTIONS の環境変数を利用することです。 JVM はこの変数の内容をコマンドラインのオプションに追加します。 次のシンタックスで Wrapper コンフィギュレーションファイルに設定できます:

set.JDK_JAVA_OPTIONS=--add-modules MODULE1,MODULE2

ただし、(wrapper.java.command.loglevel プロパティを使って)Java コマンドラインを出力するときに、起動時に JVM のみによって解析されるため、JDK_JAVA_OPTIONS のコンテンツを見ることができません。

長いオプションや JDK_JAVA_OPTIONS 変数の詳細については、Oracle 社のウェブサイト(英語)より確認できます。

乱数ジェネレータが原因で Linux での遅い起動時間を解決するにはどうすればよいですか?

「java.util.Random.nextLong()」や他のランダムなメソッドへコール(呼び出し)する Java アプリケーションは、 最初に呼び出すときに非常に遅くなる可能性があります。 これは、システムのエントロピー不足が原因です。 コールは、そのようなエントロピーが新たにたまり、適切な数を返せるまでブロッキングされます。 残念ながら、起動時に他に何も起こっていない場合、これには非常に長い時間がかかる可能性があり、 その間にアプリケーションはフリーズしているように見えます。

これが発生しているかどうかを検出する唯一の方法は、待機中にスレッドダンプ要求を発行することです。 もし、これが原因だった場合、すぐに分かります。

これが問題の原因だと判明したら、解決策として、コンフィギュレーションに次のプロパティを追加します。 これにより、Java が乱数を生成する方法が、常に高速なメソッドに変わります。 私たちは、これがセキュリティにどのように影響するかについては何も主張できませんが、セキュリティに関してはご自身で調査して、 より良い解決策があれば是非お知らせください。 尚、既存のコンフィギュレーションと重複しない数字を使用してください。

# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom

これは、プラットフォーム固有の解決策です。 プラットフォームに依存しないコンフィギュレーションが必要な場合、新しい wrapper-linux.conf コンフィギュレーションファイルを作成してください。

#encoding=UTF-8
# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom

次に、メインコンフィギュレーションファイルのプラットフォームに基づいてそちらを含めます。 その場合、番号付きプロパティを誤って再利用しないようにメインコンフィギュレーションにコメントを追加します。

#encoding=UTF-8
#include ../conf/wrapper-%WRAPPER_OS%.conf
...
# Solve slow random initialization on Linux
#wrapper.java.additional.20= # Reserved for use in wrapper-linux.conf