よくある質問

一般

JKに関する一般的な情報とFAQ

JKのヘルプ/サポートはどこで入手できますか?

サポートの主なメカニズムは、docディレクトリに含まれているJKドキュメントです。ドキュメントは、Apache Tomcat コネクタプロジェクト専用のApache Tomcat Webサイトでも利用できます。さらにヘルプが必要な場合は、Tomcat Users Discussionリストが最適なリソースです。メーリングリストアーカイブを検索してから、リストに質問を投稿してください。アーカイブで質問の答えが見つからない場合は、ユーザーリストにJKに関する質問を投稿して支援を求めることができます。Webサーバーのバージョン、使用しているプラットフォームを必ず含めてください。こちらでTomcatメーリングリストの購読方法を確認してください。

JKが見つかりません。どこにありますか?

JKがtomcat-connectorsリポジトリに移動したため、JKのソースとバイナリは、Tomcat Connectors (mod_jk) ダウンロードページのミラーからダウンロードできます。

JKとmod_jkの違いは何ですか?

JKは、WebサーバーからTomcatコネクタをカバーするプロジェクトです。

Apache HTTP Serverのサポートは、mod_jkモジュールと呼ばれるプラグインを使用してJKに実装されています。

Microsoft IISのサポートは、ISAPIリダイレクタと呼ばれるプラグインを使用してJKに実装されています。

詳細情報はどこで入手できますか?

JK 1.2.xについては、以下を読む必要があります

詳細については、リファレンスガイドをご覧ください。「JK」のメーリングリストアーカイブを検索するか、ソースを確認することもできます。

どのプロトコルを使用する必要がありますか? - ajp12、ajp13、またはajp14?

ajp13が標準です。古いajp12は非推奨であり、ajp14は実験的です。

また、ajp13はTomcat 3.2以降のすべてのApache Tomcatバージョンと、JettyJBossなどの他のサーブレットエンジンでサポートされています。

WebサーバーとTomcatの間にファイアウォールがあり、しばらくするとajp13接続が切断されます。

ajp13プロトコルは、Tomcatに送信するリクエストがない場合にトラフィックがnullになる可能性のある永続的な接続を使用します。ファイアウォールは非アクティブな接続を切断するため、WebサーバーとTomcatは接続が有効であると認識します。

JK 1.2.0以降、socket_keepaliveプロパティがajp13設定に追加されました。ワーカーハウツーworkers.propertiesリファレンスで確認してください。他に何も解決しない場合は、JkOptions +DisableReuseを試すことができますが、パフォーマンスに大きな影響があります。

高負荷時、Apache HTTP Serverが多くの負荷を処理している場合でも、Tomcatに多くのスレッドがあります。

高負荷時、Apache HTTP Serverは負荷を処理するために多くの子プロセスを作成します。これにより、処理する必要があるリクエストを転送するためにTomcatへの多くの接続が作成されます。Apache HTTP Serverは通常、負荷が減少すると子プロセス/スレッドを強制終了します。ただし、負荷がまだ存在し、Apacheのみがリクエスト(つまり、静的なコンテンツ)を処理する場合でも、子プロセスは維持され、それらと共に、もはや使用されない場合でもすべてのajp13接続が維持されます。

一定時間非アクティブな状態が続いた後で接続を閉じるには、connection_pool_timeoutを使用できます。詳細については、workers.propertiesリファレンスを参照してください。

Apache HTTP Server

mod_jkとApache HTTP Serverに関する情報とFAQ。

Tomcatを再起動するたびに、Apacheがロックアップします!

ajp13プロトコルは、TomcatとApacheの間でオープンソケットを維持します。Tomcat Connectorsに存在するmod_jkのリリースは、ネットワーク障害を処理します。ただし、非常に古いリリースのmod_jkでは、Apacheも再起動する必要がある場合があります。

Apache 1.3のダウンロードディレクトリにmod_jk.so (-eapi ad -noeapi) という2つのファイルが存在するのはなぜですか?

多くのバージョンのApacheは、mod_sslモジュールで使用するために開発された、拡張APIとして知られる変更されたAPIを使用しています。Apache 2.0以降、違いはなくなりました。

たとえば、最近の特定のLinuxディストリビューションに存在するApache 1.3には、mod_sslモジュールが含まれています。

そのため、このような「拡張Apache」がある場合は、mod_jk.so-eapiを使用する必要があります。

「標準Apache」(つまり、mod_sslなし)の場合のみ、mod_jk.so-noeapiを使用する必要があります。

STD API ApacheでEAPIモジュールを使用したり、EAPI Apacheで標準APIモジュールを使用したりしないことをお勧めします。常にApacheのバージョンに一致するmod_jk.soがあることを確認してください。

「garbled DSO?」というメッセージは何ですか?

Apache EAPIに関連しています。'mod_jk.so is garbled - perhaps this is not an Apache module DSO ?'というメッセージは、apache-mod_sslやRedhat distro 6.2/7.0のApacheのように、EAPIを使用するApacheでコンパイルされたmod_jk.so DSOモジュールをインストールしようとしていますが、システムは通常のAPIを備えた標準Apacheを使用していることを示しています。

そして、「module might crash under EAPI!」というメッセージは何ですか?

これもEAPIに関連しています。'[warn] Loaded DSO /usr/lib/apache/mod_jk.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)'というメッセージは、mod_jk.soが通常のAPIを備えた標準Apacheでコンパイルされており、EAPIを使用するApacheにモジュールをインストールしようとしていることを示しています。

mod_jkのビルド中にAPXSがrc=0またはrc=255のようなエラーを返します。ビルドセクションのすべての手順を試しましたが、どうすればいいですか?

APXSは、Apache Webサーバーをソースからビルドするときに作成されるPerlスクリプトです。これらのエラーが発生し、Apacheをバイナリディストリビューションとして入手した場合、APXSがシステム用に正しく構成されていない可能性があります。最も良い方法は、Apache HTTP ServerホームページからApacheソースを入手し、自分でビルドすることです。基本的なビルドには以下を使用します (その他のオプションについてはApacheドキュメントをお読みください)。

[user@host] ~ $ cd /usr/local/src
[user@host] ~ $ gzip -dc apache_1.3.19.tar.gz|tar xvf -
[user@host] ~ $ cd apache_1.3.19
[user@host] ~ $ ./configure --prefix=/usr/local/apache \
            --enable-module=most \
            --enable-shared=max
[user@host] ~ $ make
[user@host] ~ $ make install

注: 上記の手順では、Apacheソースをダウンロードして /usr/local/src ディレクトリに配置したことを前提としています。

Apacheが誤ったモジュールバージョンについて文句を言います。

Apache APIはバージョン間で変更される可能性があるため、Apacheモジュールには、モジュールのコンパイルに使用されたApache APIバージョンが含まれています。これはマジックモジュール番号と呼ばれます。

起動時に、ApacheはモジュールヘッダーのバージョンがApacheサーバーと互換性があることを確認します。互換性がない場合、起動を拒否し、エラーをログに記録します。

マイナーバージョンは前方互換性があることに注意してください。モジュールがApache 2.x.yを使用してコンパイルされた場合、結果のバイナリは、zがy以上である他のバージョン2.x.zでも動作するはずです。zがyより小さいバージョン2.x.zの互換性も必要な場合は、configureフラグ--enable-api-compatibilityを使用します。2.xを使用してコンパイルされたモジュールは、xがyと異なる場合、2.yと互換性がないことに注意してください。この場合、モジュールを再コンパイルする必要があります。

最新のApache 2.xで動作しますか?

mod_jkは、2.0から2.4までのApache 2.xで正常に動作します。

mod_jkの機能の重要な部分は、Apache HTTP Serverモジュールのmod_proxy_ajpとmod_proxy_balancerに再実装されています。これらはApache 2.2および2.4の標準配布の一部です。新しいモジュールにはmod_jkのすべての機能が含まれているわけではありませんが、その一方で、新しいApacheリリースごとにモジュールを自動的に入手できます。

JNIはApache 1.3では機能しません。

JNIワーカーは非推奨になりました。機能しない可能性が高いため、使用しないでください。

JNIサポートには、Apache 1.3の一般的なケースではないマルチスレッド環境が必要です。Apache 1.3がスレッドサポート付きでビルドされているかどうかを確認する必要があり、そうでない場合は、httpd.confファイルにpthreadsライブラリを追加できます。

# Add pthread to Apache in httpd.conf
LoadModule "/usr/lib/libpthreads.so"

また、JNIはマルチスレッドサーバーに適しており、JNIをサポートするためにApache 2.xにアップグレードすることを検討する必要があることに注意してください。

JNIがLinuxでJVMを起動できなかったと報告しています。

JNIワーカーは非推奨になりました。機能しない可能性が高いため、使用しないでください。

Linuxでは、Apache HTTP Serverを起動する前に、いくつかの環境変数を設定する必要があります。

export LD_LIBRARY_PATH=$jre/bin:$jre/bin/classic:$LD_LIBRARY_PATH

また、一部のLinuxディストリビューションでは、「floating stacks」と呼ばれるGLIBC機能が有効になっています。これは、SMPマシン上の2.4.10未満のカーネルでは動作しない可能性があります。環境変数をエクスポートして、floating stacksを無効にする必要があります。

export LD_ASSUME_KERNEL=2.2.5

Apacheサーバーが起動する前にこれらの環境変数を設定するために、サービススクリプト(つまり、/etc/rc.d/init.d/httpd)を更新する必要がある場合があります。

configureによるビルド時の混合エラー

configureは、システムにすでにインストールおよび構成されているいくつかのGNUツールと、最小限のlibtoolがあることを前提としています。

また、一部のシステムでは、ネイティブCコンパイラでビルドされたApacheとgccでビルドされたjkをリンクしようとすると混乱する可能性のある、ccとgccの混合設定になっている場合があります。

make処理が期待どおりに動作しない場合は、GNU make gmakeを使用する必要があります。