World Map
Java Service Wrapperは、御社Javaアプリケーション製品の安定した信頼性を高める最短最善の方法です。
  • Free Trial
  • Buy Now
トラブルシューティング

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

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

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

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

コンソール出力

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

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

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

メモリ

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

オラクルのドキュメンテーション

参照する意義のあるドキュメントとしては、オラクルのサイトです: 『Java HotSpot VM におけるパフォーマンスについて(英語)』 加えて、 『ガベージコレクション』の問題について語るとても有益な JDC Tech Tip(英語)』もあります。

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.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 起動の前/後に、何か追加プロセスをする必要があるならば、 Wrapper イベントコンフィギュレーションの機能を備えている Java Service Wrapper プロフェッショナル版をご利用ください。

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

INFO   | jvm 1    | 2011/01/06 17:23:05 | エラー: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 上でN個以上のサービスが動作しません。

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 社のウェブサイトより確認できます。