JavaOne2014 3日目メモ (9/30)
今日も晴れていて、過ごしやすい気候。3回目のJavaOneでも雨に振られたことがないので、サンフランシスコは雨が少ない地域なのだろうか。
Building a Distributed Application for the Cloud with Akka Clustering and Java 8 [TUT6483]
PlayフレームワークとAkkaを組み合わせて、最近話題のリアクティブなシステムを実現しましょうという話。
リアクティブ・マニフェストについて
詳細については原文を参照のこと。
- Responsive (応答性)
- システムは可能な限り最適なタイミングで応答すること。
- Resilient (障害からの回復)
- システムは処理が失敗した場合にも、失敗したことを応答すること。これは高可用性やミッションクリティカルシステムだけに求めるのではない - 処理の失敗時に何も応答できないシステムはResilientではない。
- Elastic (柔軟性)
- システムは大量のリクエスト下においても、応答すること。
Vert.x + WebSocket + Cloud = Awesome Map Tracking [CON1695]
Vert.xでwebsocketを実装して、以下の画面のように常に動くバス情報をブラウザ上の地図画像にアイコンとして表示するデモのセッション。RedHatが提供しているPaaSであるOpenShiftがVert.xに対応しているので、合わせてOpenShiftの紹介も少し。スライドはこちらで公開中。
セッションの冒頭で早速『今までのTomcatやJBossと何が違うの?』という質問が飛ぶ。分散環境でフレキシブルに重点を置いた新しいアーキテクチャと答える。
Going Native: Bringing FFI to the JVM [CON3979]
従来のJNIに代えて、もっと簡易にネイティブコードが呼び出せる仕組み JNR (Java Native Runtime)に関するセッション。スピーカーはJRubyの開発者であるCharles Nutterさん。JNRについてはgithubにて公開中。
JRubyを作っていて困った事
Javaで作られているJRubyを作るにあたって、OSレベルへのアクセス、例えばファイルシステムアクセスや、グラフィック/暗号化などのネイティブライブラリへのアクセスで困っている。しかし既存のJNIは使いにくい面も多い。もっと簡単にネイティブコードが呼び出せる仕組みがあると良い。
JNRのコード例
現在のプロセスIDを取得するlibcのgetpid関数を呼び出す例。とても直感的なコード例になっている。
import jnr.ffi.LibraryLoader; import jnr.ffi.annotations.IgnoreError; public class GetPidJNRExcample { public interface GetPid { @IgnoreError long getpid(); } public static void main(String[] args) { GetPid getpid = LibraryLoader.create(GetPid.class) .load("c"); getpid.getPid(); } }
JNRの構成要素
ユーザレベルの関数だけでなく、色々なネイティブ関数にアクセスできる。例えば以下のようなもの。
- jnr-posix : POSIX準拠の関数をJavaから実行
- jnr-unixsocket : unix socketをJavaから実行
- jnr-x86asm : x86アセンブラをJavaから実行
The Modular Java Platform and Project Jigsaw [CON5435]
前々から検討されているJDKへのモジュールシステム導入 Project Jigsaw に関するセッション。
互換性の維持と新機能の要望により増え続けるJDKのコアAPI実装にモジュール化システムを導入して、使いたいモジュールのみをロードする仕組みを作る。デモではrt.jarがなくなったよとのアピールがあり。
jlinkと呼ばれるツールで依存性を管理するらしいが、詳細は理解できなかった。JDK9のEarly Accessには今のところJavaOneでデモがあったjlinkやrt.jarの削除が盛り込まれていないので、JDK9のEAにマージされるのが待ち遠しい。
Troubleshooting with Serviceability and the New Runtime Monitoring Tool HeapStats [BOF3108]
NTT OSSセンタが開発したJavaトラブル解析支援ツール HeapStats のBOF。NTT OSSセンタはNTTグループ会社向けのOSSのテクニカルサポートを提供しており、頻出トラブルとトラブル解決の迅速化を目的に開発されたHeapStatsの紹介が行われた。
よくあるトラブルについて
OSSセンタに寄せられたサポート依頼では、ヒープ関連のトラブルシュート依頼が特に多かった。
トラブルシュートの課題
情報がない
ヒープのトラブルが多いが、トラブル発生時のヒープダンプが残っていない事も多く、-XX:+HeapDumpOnOutOfmemoryErrorをトラブル発生後に追加してもリークスピードが遅く、再現に数ヶ月かかるケースもあった。
既存ツールは重い
ヒープダンプは取得に時間がかかるためサービス影響が大きく、ヒストグラムではオブジェクト間の参照が見れないため解析情報が不足する。