- PR -

Apacheの常時稼動について

«前のページへ 1|2
投稿者投稿内容
MyTime
ベテラン
会議室デビュー日: 2002/01/03
投稿数: 83
投稿日時: 2002-09-03 23:17
　glibcのposixスレッド関連の処理を行っているpthreadライブラリに問題があり、ある条件でJVMが無応答になる不具合ががあります。発生率は、glibcのバージョンにもよりますが、該当処理の数千〜数万回に１度という程度のものです。Redhat 7.3用の最新のカーネルとglibcを使用すれば、他のバージョンに比べれば、かなりましな状態になります。(今現在も完全には、解決していません。) Redhat AS以前のバージョンについては、この問題に関する限り、手付かずといっても良い状態です。
　この問題は、セキュリティー問題こそ起こしませんが、かなり根深いものになっています。ミドルウェアを出荷しているメーカーによっては、この問題を避けるために、自家製のglibc以外での動作を保証していないところもあります。(ベースとなるglibcやカーネルにセキュリティーホールが見つかっているのに、出荷時からほとんどアップデートされていないこれらのモジュールは大丈夫なのだろうか？)
　対症療法的になりますが、redhatの場合には、アーキテクチャがi386であるパッケージに切り替えれば、一部の問題は発生しなくなることが、わかっています。webサーバを多重化した上で、時間差で２４時間に１度はリブートするような運用をすれば、運用で対応することもできます。

＊以下は愚痴です。
　自分たちの製品に都合がいいように共有のライブラリにパッチを充てた自家製版のライブラリを使用することを強要するベンダが増えてきています。オープンソースなんだから、ソースさえ公開していれば、何をしてもいいといわんばかりの態度には、迷惑しています。マルチベンダとなると地獄です。A社は、A1を使えというし、B社は、B2を使えという。ディストリビュータは、ディストリビュータでセキュリティーや不具合修正で、どんどんリビジョンアップしていく。Redhat 7.3だけでも、ここ数ヶ月の間に、何度もカーネルやglibcのアップデートを繰り返している。エンタープライズ向けに鳴り物入りで販売されたRedhat ASにしても、高い金を取るだけで、Redhat 7.2と同程度にアップデートを頻発している。いったい、どれを使ったら、安定していてセキュアな動作環境になるのだろうか？
　　
ゆじ
会議室デビュー日: 2002/09/02
投稿数: 8
お住まい・勤務地: 東京都
投稿日時: 2002-09-04 10:02
ZZZさん、MyTimeさん貴重なご意見ありがとうございます。
とても勉強になります。この問題が発生したときは２時間に一回リブートをかけていました(泣)。どんなWebサーバーでしょう！

意見を頂いてもすぐに対応できない自分の無知を恥ずかしく思いますが
とにかく、あせらず冷静に対処していこうと思います。

ところで、昨日も一晩中サーバーを立ち上げていきました。
朝、いつもだったらタイムアウトでアクセスできないのが、今日はアクセスすることが出来ました。しかし、データベースの中身を読みに行っていないため何も表示されないという現象でした。(ちなみに現在動かしているServletは、いわゆるスケジュール帳です。データベースはmysql3.23.49を使用しています)

ApacheとTomcatのログには何も記録されていません。

設定を変えたとすればhttpd.confのStartServers(初期サーバープロセス数)をデフォルトで８だったのを１にしたくらいでしょうか。何の影響か分かりませんが検証する必要がありそうです。ちょっと具合が悪くなってきました。

それでは失礼します。
ゆじ
会議室デビュー日: 2002/09/02
投稿数: 8
お住まい・勤務地: 東京都
投稿日時: 2002-09-04 22:33
お世話になってます。ゆじです。

今回は報告です。
このスレッドの一番最初に投げたバグが出なくなりました(やったー！)。

原因の詳細は分からないのですが、Tomcatの設定を行う"servet.xml"の記述の中に
Webアプリケーションを関連付けるだめ

Context path="/servlet_name" docBase="servlet_name"
debug="0" crossContext="true" reloadable="true" >

と言った記述をしいますが、この中の"reloadable"の設定を解除すると固まらなくなりました。
tomcatの起動時に、Webアプリケーションのロードを1回だけ行っていることがログを見て分かったのですが、私の作ったスケジュール帳Servletだけが延々リロードを繰り返しているのでした。きっかり15秒おきに、作業ディレクトリへのロードを繰り返しておりこれがtomcatに負荷を与えてしまっていたようです。
今まで、これが普通なのだと思っていたため全く目もくれていませんでした。
こんなネックになりそうなバグを皆さんにお伝えできず申し訳無いです。

今日の朝、Servletにアクセスできたのも"server.xml"の設定を直していたからでした。

この件もなぜロードを繰り返すのかが分かっていないので、それについて検証することが私の次の課題です。
自分の作ったServletだけがロードを繰り返すと言うことは、やはりソースに問題があるのでしょうか？

そういえばデータベースへのアクセスについてもバグがありました…。
やはりログの中に
java.util.zip.ZipException
java.util.jar.JarException
があったので、mysqlのJDBCドライバ(mysql.jar)への接続が死んでいると睨んでいます。

とりあえず一つ壁を超えることができました。いろいろなご意見、非常に感謝しております。
ありがとうございました。

今後ともよろしくお願い致します。
まりり
ぬし
会議室デビュー日: 2001/12/05
投稿数: 329
投稿日時: 2002-09-05 01:31
Tomcatをちゃんと触っていませんが、リロードはコンテナ側が行なうものですから、
ソースの問題ではないでしょう。

> と言った記述をしいますが、この中の"reloadable"の設定を解除すると固まらなくなりました。

まさにここがリロードの理由なのではないですか？
はずしてるかな・・・
ゆじ
会議室デビュー日: 2002/09/02
投稿数: 8
お住まい・勤務地: 東京都
投稿日時: 2002-09-05 09:58
まりりさん、ご回答ありがとうございます。

私が読んだ内容では"reloadable"設定を有効にしておくと、Servletのクラスファイル(JSP等も？)を変更したときに、tomcatを再起動しなくても新しいクラスファイルを認識してくれる効果があるということでした。

今のところTomcatの稼動中に特にソースファイルをいじっているわけでは無いので、"reloadable"を有効にしていても関係無いはずなのですが、実際Webアプリケーションをリロードするという現象が起きています。
H2
ぬし
会議室デビュー日: 2001/09/06
投稿数: 586
お住まい・勤務地: 港
投稿日時: 2002-09-05 10:56
しょっちゅうリロードするのはちょっとおかしいですね。何かが、定期的にServletのファイルをtouchしてませんか？

ReloadableをONにしておくと、Servlet（JSPは含まれない）のファイルの日付が変わったときにリロードしてくれます。何かが定期的にそのクラスファイルを触っているので、ファイルのタイムスタンプが変わってしまいリロードされるのではないでしょうか。
ZZZ
会議室デビュー日: 2001/08/10
投稿数: 17
投稿日時: 2002-09-05 12:17
ZZZです。Tomcatのクラスローダーにバグがあるため、reloadableを開発時以外に使わないでください(開発時も出来る限り使わないよう)。trueにすると、同じローダーを使ってクラスをロードしてくれる保証などが一切ありません。ソースを読んだが、ローダーにところに"// ここに問題あり、誰が何とかしてくれ"っていうコメントがありますよ(もちろん英語です。自分なりに訳しただけです)。しかし、reloadableをtrueにしたから固まるっていうのはちょっと不思議です。大体の場合、ClassNotFoundなどのroader周りのExceptionしかでないはずです。やっぱりゆじさんはソースを公開しないと、突き止められないと思いますが・・・
ゆじ
会議室デビュー日: 2002/09/02
投稿数: 8
お住まい・勤務地: 東京都
投稿日時: 2002-09-06 09:44
お世話になっております。ゆじです。

返事が遅くなってしまい申し訳ありません。
H2さん、ZZZさんご回答ありがとうございます。

結論から言って"reloadable"がからんだバグは
Servletのクラスファイルを格納する"webapp/servlet_name/WEB-INF"ディレクトリの下にある"xercer.jar"ファイルが原因でした。

みなさんの意見を参考に、どうしてみようかと迷った末、クラスファイルが勝手にアップロードされている可能性があるということで、クラスファイルを消してみました。

スケジュール帳のServlet関連のファイルをひとつづつ削ってみましたところ、クラスファイルやJSPファイルをディレクトリごと削除しても、エラーを吐いていました。そして最終的に"xercer.jar"を削除したことで"reloadable"による影響が無くなったのでこれだ！ということになった次第です。

そもそもどこから持ってきたのかを忘れてしまったのですが、配置してあった"xercer.jar"は何か壊れていたらしく、"$TOMCAT_HOME/commom/lib"の下にある"xercers.jar"を改めて置いたら上手く動きました。

いろいろ考えていただき、本当にありがとうございました。
結果的に、壊れていた"xercer.jar"ファイルが"reloadable"の動作に影響を与え、その"reloadable"がtomcatに対し作業ファイルのロードを延々とやらせることで、一連のエラーが起きていたということです。

今後、質問等を投げる場合は開発環境やエラーの状況をより明確に伝えることを心掛けていきます。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）