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

Wrapperバージョン3.0.5から、 ［wrapper.pidfile］プロパティが Windoesプラットフォーム上で実装されるようになりました。 それ以前のWrapperバージョンでは、Windows上で動かしても、このプロパティは無視されます。 しかしながら、もし、ご利用中の 「wrapper.conf」ファイルが Wrapperバージョン3.0.0よりも以前のWrapperを使って作成されたものであるなら、 「wrapper.conf」の例からファイルをコピーして使った時点以降、 そのまま使っている定義された、このプロパティを持っている可能性があります。 この場合、以下のようなエラーが引き起こされると思われます：

エラー: pid ファイルを書き込めませんでした /var/run/testwrapper.pid: The
system cannot find the path specified. (0x3)

この問題を解決するには、単純に「wrapper.conf」ファイルをエディタで開いて、 ［wrapper.pidfile］プロパティを削除してください。

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

WARNING - Unable to load native library 'wrapper' for class WrapperManager.
          System signals will not be handled correctly.

Wrapperバージョン2.2.9時点で、このエラーメッセージが改善されました。 以下のように表示されるでしょう（もちろん利用中のプラットフォームに応じて異なります）：

WARNING - Unable to load native library 'wrapper' because the
          file 'Wrapper.dll' could not be located in the following
          java.library.path:
            C:\SourceForge\wrapper\bin\..\lib
          Please see the documentation for the wrapper.java.library.path
          configuration property.
          System signals will not be handled correctly.

Windows 2000 や NTでは、管理者権限のないユーザーでログインしている状態で、 サービスのインストールを試みた場合、以下のようなエラーメッセージが表示されます。

OpenSCManager failed - access denied.

この問題の解決には、システム・アドミニストレーターに連絡をして、 サービスをインストールするようにお願いをしてください。

その原因の理由を説明している出力がコンソールに表示されているはずです、 同様にログファイルにも出力されているはずです。 さらに詳しい出力を得るためには、 利用中の「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（Javaバーチャルマシン）をご覧ください。 Java Service Wrapperバージョン3.4.x以上では、JVMバージョン1.2.xをサポートしていません。

Wrapperバージョン3.4.xより古いリリースのWrapperのほとんどの機能は、JVMバージョン1.2.xで動作しますので、 しかしながら、リリースされたWrapperは、Java 1.4.xバージョンを使ってビルドされています。 JVMバージョン1.2.xは、生成された「jar」に問題があり、とても低いレベルのJNIエラーでクラッシュします。 この問題は、Java 1.4.xバージョンのコンパイラのバグと思われ、 クラスのコンパイル時にJVMバージョン1.1をターゲットにして作成しても発生します。

私が見たエラーの一例を紹介します：

A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in :
  'org/tanukisoftware/wrapper/WrapperManager.stopCommon (II)V': Interpreting method.
  Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi

何名かの方からヘルプをいただき、様々なプラットフォームに対応したリリースを発行することができました。 Wrapper配布をビルドする際に古いJDKを使うように皆さんに強制するわけにはいきません。

もしWrapperやJVMバージョン1.2.xを使っていてクラッシュ問題に悩んでいる場合、 試しに、ディストリビューション・ソースをダウンロードして、お持ちのJDKバージョン1.2.x を使って、 wrapper.jarをビルドしてみてください。 それで問題が修復されるでしょう。

もし、まだこの問題に遭遇して困っている方は、 Wrapper-Userメーリングリスト にメモを投函ください。 どのくらいの人数の方が、今もなおJVMバージョン1.2.xを利用しているか把握していません、 しかし、もし比較的、多数のユーザーがいるならば、上記の方針を再検討することもありえますし、 古いJVMを使ってビルドしたリリースを出すまでの所要時間を調べてみます。

Java Service Wrapperは、JVMの健康状態のチェックにping機能の仕組みを使っているため、 もし30秒以上の長い時間、他のプロセスがCPUの100%を消費している場合、実際にはJVMがハングアップしていなくても、 JVMがハングアップしていると想定してしまうことがあります。 これにより、ログファイルに以下のようなエントリが生成される結果になり、JVMが再起動されます：

jvm 1    | 2001/12/01 12:23:23 | start()
wrapper  | 2001/12/01 12:23:44 | スタートアップ失敗: JVMからのシグナル待ちのタイムアウト。
wrapper  | 2001/12/01 12:23:44 | JVM はリクエストに応じて終了しませんでした、中止しました
wrapper  | 2001/12/01 12:23:49 | JVM起動中...
jvm 2    | 2001/12/01 12:23:50 | 初期化中...

conf/wrapper.logの ［wrapper.ping.timeout=30］プロパティは、 タイムアウト時間を設定するのに使います。 しかし、これは本当の問題が発生したイベント時でも、 アプリケーションがハングアップして残る時間の長さでもあることに注意してください。

この問題は、 ［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プロフェッショナル版をご利用ください。

この問題も同類で、上記と同じ理由により引き起こされています。

INFO   | jvm 1    | 2009/10/23 14:35:48 |  WrapperJNI エラー: JVM プロセスへBREAKイベントを送信できません。: The parameter is incorrect. (0x57)

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

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)デフォルト と互換性がありません。

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

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.exe」「wrapperW.exe」「wrapper.dll」） には、弊社タヌキソフトウェアからの純正ファイルであるか認証する協調設計を利用しています。 何か問題を検知すると、Wrapperをシャットダウンします。

弊社の副署名（Comodo UTN-USERFirst-Object）のため、 上記のエラーが発生しました。Windows Certificate Manager（証明書管理）の 「certmgr.msc（証明書MMCスナップイン）」で、 インストールされた証明を調査することができます。 この「UTN-USERFirst-Object」証明書は、「サードパーディ・ルート証明機関￥証明書」 に入っているはずです。もし入っていなければ、そのルート証明書を以下からダウンロードできます：

https://support.comodo.com/index.php?_m=downloads&_a=viewdownload&downloaditemid=79

もし、それがあるということは、つまり、 サーバーのローカル・セキュリティ・ポリシーが厳しすぎて、その証明書を承認できない、という意味でしょう。 この設定は、サーバーのローカル・セキュリティ・ポリシー「公開キー・ポリシー\Certificate Path Validation Settings"」 にあり、ルート証明ストア「サードパーティ・ルート証明機関(CA)およびエンタープライズ・ルート証明機関(CA)」を許可します。 もし設定を有効にできない／有効にならない場合、他の手法として、 「UTN-USERFirst-Object Certificate」を 「サードパーティ・ルート証明機関」フォルダから 「信頼するルート証明機関」フォルダへ動かすことです。

Wrapperバージョン3.5.8では、 署名が認証できない場合にだけWrapperがシャットダウンします、 これは副署名の問題によるものではなく、直接Wrapperによってシャットダウンされています。

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

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