JKって何？
JKは、ワイヤプロトコルです。
Apacheといった外部WebサーバがTomcatと通信するためのHTTPプロトコルの応用版です。
これまでの歴史において、Apacheは、静的なコンテンツの配信能力において、Tomcatより格段に速いです。
考え方として、静的なコンテンツの配信をApacheに可能な限り処理させるようにし、Tomcat関連のコンテンツについてはTomcatにその要求を転送させるようにします。
JK、JK2、mod_webapp、mod_proxyの違いは？
-
mod_webapp(別名:warp)については、もう忘れてください。
開発者の関心がなくなったのと、JKやJK2のような優れたオプション指定ができないため、非推奨扱いかつサポート廃止となっています。
-
mod_jservは悪くないのですが、私の知る限り、サポートはなくなりましたし、Tomcat 5でもサポートは行われないでしょう。
-
mod_jkは大変優れていて、開発作業でぜひ利用すべきです。必要に応じてバグ修正も行われています(品質的にしっかりしています)。
-
JK2はmod_jkをリファクタリングしたもので、Apache Portable Runtime(apr)を使っています。
Apache 2.0を利用しているのであれば、たぶんJK2を使いたいはずです。
しかしながら、皆さんの開発作業にふさわしくないかもしれません。
-
mod_proxy。その考え方に興味がありますし、重いロード処理に多大な問題があるようには見えません。
JK、JK2のいくつかの機能を必要としなければ、これは大変シンプルな代替品です。
どうして、ApacheをTomcatに連携させないといけないの？ (or 連携しなくてもいい理由とは？)
TomcatとをApacheの連携には、いくつか理由があります。そして、そうすべきでない理由もあります。
言うまでもないですが、このときに皆さんは、委譲処理を考えるという見解には反対するでしょうね。
Tomcatの最新のパフォーマンスでは、パフォーマンスの理由を正当化するのは困難です。
だから、連携構築すべきかそうでないかを議論した問題がここに紹介されています。
-
クラスタリング。
Apacheをフロントエンドとして運用することによって、複数のTomcatインスタンスに対するコンテンツの受付窓口として動かすことができます。
それらのTomcatのうちの1インスタンスが落ちたときに、Apacheはそれを無視しますので、システム管理者は夜間眠りにありつけます。
-
クラスタリング/セキュリティ。
異なるURL名前空間(/app1/、/app2/、/app3/、または、仮想ホスト)に対応する各々のTomcatに対し、Apacheを受付窓口として運用することもできます。
-
セキュリティ。
このトピックでは、どちらにも使えます。
Apacheがより大きなMindshareやセキュリティに関するより多くの小技を持っていると同時に、Javaにはセキュリティマネージャを装備しています。
このことを詳しく取り上げるつもりはありませんので、その際はGoogleを役立ててください。
しかしながら、あなたのシナリオ次第で、一方の機能が、他方より適しているかもしれません。
でも、ApacheとTomcatを連動させる場合には、このことを心の隅に置いてください。
防御目的に2つのシステムを用意することもあるし、そうでないこともあります。
-
アドオン。
CGI、Perl、PHPの追加は、Apacheに対して、結構普通の話ですね。
Tomcatは結構遅いし、さらに多くのクラッジがあります。
TomcatはCGIを実行することが可能ですが、PHP、CGI、mod_perlと同様にTomcatのサービスを考えてみてください。
Apacheは、必要なときにプラグイン可能なモジュールを何百個も実装しています。
Tomcatはこの機能を実装可能ですが、コードはまだ書かれていません。
-
拡張機能！
Tomcatの手前でApacheを使うことにより、Tomcatがサポートしない、もしくは、中間コードをサポートしていない、多くの拡張機能を実行可能です。
例えば、mod_headers、mod_rewrite、mod_aliasは、Tomcat用に書くことも可能です。
しかしながら、Apache側で十分に機能しているモジュールを、なぜ再度開発し直す必要があるのでしょうか？
-
処理速度。
ApacheはTomcatに比べ、静的なコンテンツを配信する処理が速いです。
しかしながら、かなり混雑するサイトでない限り、この点は役に立ちません。
-
ソケットのハンドリング/システム性能。
ApacheはTomcatに比べ、エラー状況に関するソケットのハンドリング処理が優れています。
主な理由として、Tomcatはクロスプラットホームを必要とするJVM経由で、ソケットのハンドリング処理をすべてこなさないといけないためです。
問題は、ソケットの最適化がプラットホーム特有の苦難であることです。
通常では、Javaのコードはうまく書かれていますが、接続の切断、無効なパケット、無効なIPからの無効な要求を送りつけられたとき、ApacheはJVMベースのプログラムに比べ、これらのエラー状況を非常にうまく切り抜けています。
-
ここには、
Craig R. McClanahan氏からのすばらしいレスがあります。
空いた時間がありましたら、メーリングリストのアーカイブにある、彼からのEメールを読んでみてください。
たくさん学ぶことになるでしょう。
ブート時において、起動する順番 (Apache vs Tomcat) は重要なの？
いいえ。
このことですが - ApacheとTomcatは、一方の稼動状況に関係なく、いつでも再起動可能です。
shmファイルの生成やTomcatに割り当てるURI一覧のマッピング定義を記したworkers2.propertiesに関して、JK2が自分の設定した内容を読み込んでくれません。
何がまちがっているの？
JK2が
workers2.propertiesファイルを参照していません。
httpd.confファイルに下記の行を追加して、
workers2.propertiesファイルの格納場所を指定してください。
JkSet config.file /full/system/path/to/workers2.properties
この質問の元となったスレッドはこちらです。
mod_jk.conf-autoを自動生成する方法はないの？
それを追加するコマンド類を必要としているんです。
本当に必要な機能ではありません。
自動生成されたmod_jk.conf-autoをコピーし、あなたの好みに合わせて手作業で編集してください。
現状、Tomcatを構築している運用環境において、mod_jk.conf-autoを実際に使用しているところは１件もないです。
指定したIPアドレスにバインドするには、どうしたらいいの？
