- - PR -
Exceptionを吐かずに処理がとまる
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-08-30 23:41
jdk1.4.2
Red Hat5 Tomcat5.0.28 頻繁にお世話になっております。 現在、稼動中のアプリケーションがあります。 その中の一部が、どういうタイミングか不明ですが突然動かなくなります。 諸事情により、プログラムが落ちるタイミングは、プログラム上にログに吐くメッセージを書いて探ることしかできません。（＝デバックが出来る環境がありません） 上記方法で、プログラムが落ちるタイミングを調べたところ、その部分にはTry、catchで囲まれており、Exceptionでcatchして、メッセージを表示するようにしておりました。 それにもかかわらず、ログにメッセージは吐かれませんでした。 そして、何よりも不思議なのが、プログラムが落ちる部分のclassファイルを再度アップしなおすと、再び動きだします。（ちなみに、FFFTPのバイナリでclassファイルをアップします） とりあえず、確認できた動かなくなったタイミングは、稼動中のマシンのIPアドレスや、ドメイン情報などを変更したタイミングでした。 動かなる場所は常に同じ部分です。この場合もclassファイルの再アップで動くようになりました。原因が全くわかりませんし、デバックできない環境でのエラーのハンドリング方法も考え付きません。 どなたか、ご存知の方がいらっしゃいましたら、お助けいただきたいと思います。 何卒宜しくお願い致します。 | ||||||||
|
投稿日時: 2008-08-31 00:57
Exception ではなく、Error が発生していて catch 出来ていないのではないでしょうか？
標準エラー出力に何か記録されていませんか？ | ||||||||
|
投稿日時: 2008-08-31 01:10
環境の情報はどこに記述していますか？ 定数としてクラスに定義している場合、 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=31843&forum=12&2 このケースに当てはまったりしませんか？ どのみち、デプロイ方法をもうちょっと詳細に書いてもらえませんか？ アップの前後に何をしたのかも、書かないとわからないですね。 修正したクラスファイルだけをアップしていると、 NoSuchMethodErrorの類を起こしやすいので、 あまりお勧めできません。きちんとWARファイルでデプロイしたほうがよいでしょう。 仮に何かのExceptionではなくErrorがスローされていると仮定して話を進めますが、 ErrorクラスはExceptionクラスのサブクラスではないため、 catch(Exception e)では捕まえられません。 本来やるべきではありませんが、どうしても捕捉したいのであれば、 catch(Throwable e)で捕捉するとよいでしょう。 とにかく実際の業務のコードに入れるべきではないので、テストの間だけにしましょう。 | ||||||||
|
投稿日時: 2008-08-31 02:24
＞インギ様
度々大変お世話になっております。 ＞Exception ではなく、Error が発生していて catch 出来ていないのではないでしょうか？ そういう可能性が多分にあります。気になる点とすれば、毎回この症状がおこるわけではなく、あるタイミングで起こる点です。Errorが発生するにしても毎回起こってもよさそうなものに・・と不思議に感じています。 ＞標準エラー出力に何か記録されていませんか？ System.err等は仕掛けていないようでした・・・Exception等のエラーを吐くファイルについては確認しましたが、全く出力されておりませんでした。 もしかしたら、Exception等の処理をしていないのかもしれません。確認してみます。 毎回、大変ありがとうございます。 ＞かつのり ご解答いただき大変ありがとうございます。 ＞環境の情報はどこに記述していますか？ すいません、こちらの「環境」とはどういったものをさしていますでしょうか？ 不勉強で申し訳ありませんが、教えていただけると幸いです。 ＞このケースに当てはまったりしませんか？ もしかしたら、あるかもしれません。今回のプロジェクトでは、classファイル単位でアップしているようで、確かに、それを使用しているクラスまでコンパイルしてはいません。そうすると、おっしゃることが起こる可能性が高いと言えます。ファイル単位でアップするのは、根本的にリスクが高過ぎるということが言えるのですね。 大変たすかります。調査します。 ＞どのみち、デプロイ方法をもうちょっと詳細に書いてもらえませんか？ ＞アップの前後に何をしたのかも、書かないとわからないですね。 大変申し訳ありません。デプロイ方法は以下のようにしました。 ①eclipseからコンパイル（jdk1.4.2）して、classファイルを作成 （処理がとまった時点のjavaファイルを再度コンパイルしclassファイルを作成） ②このファイルをTomcatのwebappの下に配置してあるアプリケーションの所定の位置にFFFTPのバイナリモードでアップ。 ③Tomcat、Apacheを再起動 ＞修正したクラスファイルだけをアップしていると、NoSuchMethodErrorの類を起こしやすいので、あまりお勧めできません。 ＞きちんとWARファイルでデプロイしたほうがよいでしょう。 ありがとうございます。大変勉強になりました。今までWARファイルでアップしないということを考えたことがありませんでした。が、実際classファイル単位でアップしている環境に遭遇したときに、WARファイルの意義を考えずclassファイル単位であげてしまっていました。 このような致命的なErrorがでる可能性が高いとわかったので、WARファイルでアップする方向にできるように打診してみたいと思います。 ＞catch(Throwable e)で捕捉するとよいでしょう。 このような方法があるのですね。テスト環境でのみぜひ、試したいと思います。 | ||||||||
|
投稿日時: 2008-08-31 02:44
単に、
と、書いてあったので、動作環境の設定内容を定数などに記述していたりするような、 そんなつくりのシステムじゃないかと思っただけです。 動作条件の不整合（実際のサーバの環境と、IP等の設定情報との不整合） ↓ 何かしらの例外発生して例外処理へ ↓ クラス情報の不整合 ↓ Errorがスローされる と考えたわけですが、あんまり気にしなくても結構です。 | ||||||||
|
投稿日時: 2008-08-31 03:10
＞かつのり様
度重なるご返答誠にありがとうございます。 ＞と、書いてあったので、動作環境の設定内容を定数などに記述していたりするような、 ＞そんなつくりのシステムじゃないかと思っただけです。 すみません、書き方が不適切ではありませんでした。 「稼動中のマシンのIPアドレスや、ドメイン情報などを変更したタイミングでした」 というのは、既に稼動中のアプリケーションがのったマシンのIPアドレスやドメインを GUIから変更しマシンを再起動したというタイミングのことで、アプリケーション上で、動的に変更しているというわけではありませんでした。 ＞動作条件の不整合 ＞クラス情報の不整合 確かに、ありうるお話だと思います。 再度確認しなければないと思いました。 早急に確認してみます。 大変ありがとうございます。 | ||||||||
|
投稿日時: 2008-08-31 13:46
現在エラーが発生した際にどこに記録されるのかどうかも確かめておくと良さそうですね。
<%=throw new Error()%> とだけ書いた jsp を叩いてみるとかして。 | ||||||||
|
投稿日時: 2008-08-31 19:06
＞インギ様
度重なるご返答、誠にありがとうございます。 ＞現在エラーが発生した際にどこに記録されるのかどうかも確かめておくと良さそうですね。 確かにそうでした。まだ、全体像を把握していないのでエラーが発生して、どこに記録されるかも確かめなければならないです。 沢山のアドバイスとご教示ありがとうございます。 現在、管理上作業がストップしております。 作業開始次第、または何か判り次第ご報告させてください。 本当にありがとうございます。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。