Javaの開発者でEclipseを利用されている方は多いと思います。 通常のEclipseをインストールするとJavaの開発用ツールが一式はいりますが、その中にJavaのデバッグツールも含まれます。 TomcatやJetty、WebLogicなどのWebアプリケーションサーバ上で動くWebシステムを開発する際、ローカルにWebアプリケーションサーバを入れその上で動かしながら開発を進めていくのが一般的だと思います。 EclipseではTomcatプラグインなどWebアプリケーションサーバ固有のプラグインでのデバッグ実行、もしくはEclipseに「サーバ」としてWebアプリケーションサーバを登録し、そこからデバッグ起動することでEclipseからデバッグをすることができます。では、手元のマシン(ローカル)以外で動いているアプリケーション(Webアプリはもちろんバッチなど)はどのようにしてデバッ
OutOfMemoryErrorが発生してもスレッドを異空間に葬るだけでJava VMはそのまま動き続ける場合があるけど、当然ながら状態に一貫性のない状態で動いている可能性があるわけで基本的にはとっとと死んで欲しいわけである。一般的に言うところの「不定」状態。OOMEはErrorであってふつうの例外ではなく、致命的なJava VMエラーを示すものである。OOME発生後にプロセス再起動しないでそのままどうこうしようというのは絶対に避けた方が良い。 例えばJDBCのコネクションオープンしてDBからデータを読み込んでるときにOOMEが起きた場合、JDBCコネクションは大抵オープンしっぱなしで回収はされなかったりする。OOMEではfinallyブロックが呼ばれる保証はない。JDBCコネクションリークくらいならまだ良い方だが、これは全てに当てはまる。A-B-Cといったセットになっている処理は例外など
Javaのデバッグをしていて、ステップ実行中にステップインを繰り返したらソースコードのないところに行き当たったことがあるだろう。あるいはEclipseでF3キーでクラスやメソッド・フィールドの宣言元を辿っていってソースコードのないところに行き当たったことがあるだろう。 Eclipseの場合、"Class File Editor"というものが開く。そこにはJavaのバイトコードのニーモニックがズラズラと並んでいて、「これは読めないや、ワケが分からない」と投げ出してしまったりしていないだろうか。 怖がることはない。ちょっとコツを掴めばすぐに読めるようになる。 Class File Editorの開き方 自前のJavaクラスの場合、ビルドして出来上がったclassファイルを開く必要がある。"Package Explorer"だとclassファイルは隠されていて見えないのでWindow -> Sh
@higayasuoさんのつぶやき： #appengine でリクエストを処理するスレッドは1インスタンスあたり1つという仮定は正しい。ただし、インスタンスの特定にRuntimeのhashCodeを使うのは間違いでFilterなどで起動時にServletContextにUUIDなどを突っ込んで調べるのが正しい#appengine でJavaのRuntimeは多くのアプリケーションで共有されていて同じアプリケーションの複数インスタンスで共有されることもあるなるほど、、そこで今度は、Runtime.getRuntime().hashCode()の代わりに、ServletContextにUUIDを入れて識別する方法でTask Queueのコンテナインスタンス単位の負荷分散状況を調べてみました。こんなコードをサーブレットに書いて、ランダムIDを取得します。 final ServletContext
ご存じのとおり、App EngineのJVM（App Server）はクラスタ化されていて負荷分散される――というのがGoogleの説明です。しかし、WebブラウザからApp Engineに届くHTTPリクエストや、Task Queueのタスクによって呼び出されるHTTPリクエストは、実際にどのような感じで複数のJVMに配られるのでしょうか？ どれくらいの量のリクエストが届いたとき、何台のノードに負荷分散される？ 負荷分散のアルゴリズムは？（単純ラウンドロビン、sticky session/session affinity、負荷状況に応じた転送など） 新しいJVMの追加や、既存のJVMの削除のタイミングは？ これらについてはGoogleから情報が公開されておらず、謎です。そこでApp Engine利用者の皆さんが実際の経験やテストを通じて情報を交換しながら想像たくましくするしかないわけです
Javaにおける開発環境の進歩と同時に、ブラックボックス化とそれにともなう課題も発生している。開発現場での課題解決を図る連載第1回では、互換性とサポート期限に焦点を当てる。 Javaにおける開発環境は急速に進歩しており、現場では次のような課題が発生している。すなわち「IDEすなわち統合開発環境の活用により順調にプログラムは完成したが、デバッグ段階においてJava VMに起因する問題に遭遇しJavaを取り巻く環境のブラックボックス化が進んだため、いかにして問題を解決すべきか分からない」といったものである。このような声に応えるため、本連載では次の課題を中心に、ブラックボックス化されたJava環境について解説する。 コンパイラの互換性 JavaVMのバージョンとサポート期間 JavaVMのメモリとGCの特性 Full GCの問題 文字コード変換の影響 マルチスレッドアクセスの配慮 性能問題の原因
Javaの黎明（れいめい）期、多くの人々にJavaが知られ、広まった理由の1つは、WebブラウザにJava VMが組み込まれたことにあるでしょう。その当時のWebブラウザ開発のエキサイティングな様子は、雑誌『Wired』の古い記事「The Java Saga」で読むことができます。 Webブラウザ上で動作するJavaアプレットの勢いも借りて、各OSベンダが米サン・マイクロシステムズからライセンス提供を受け、各OSプラットフォーム用のJava環境が続々とリリースされます。 その一方、米マイクロソフトのWebブラウザ「Internet Explorer」（以下、IE）にJava VMが組み込まれたことは、歓迎とともに混乱を招きました。米マイクロソフトが提供したWindows 95／NT用のJava VM（(MSJVM)）が持つ「J/Direct」機能は高性能ながら、Win32 APIを直接呼び
J2EEがミッションクリティカルな分野に適用されるようになり、Javaのパフォーマンスチューニングの重要性はさらに高まっています。パフォーマンスチューニングにはさまざまなパラメータがありますが、中でもJava VMに関連するチューニングの効果は大きいといわれています。本稿は、Java VMに関連するチューニング手法を学ぶための前提知識を提供することを目的にしています（編集部）。 Java VMに関連するチューニングを行い、J2EEアプリケーションのパフォーマンスを上げるためには、Java VMについて詳しく知る必要があります。本稿は2回に渡ってJava VMの基本構造と動作原理を詳細に解説しますが、内容を理解するためにはプログラムがコンピュータ上で動作する基本原理とJava VMの基本用語を知っている必要があります。Java VMの基本用語に関しては、「実行スピードに挑戦するJavaアーキ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く