Archive for 4月, 2009

Atmosphere 0.1 GA リリース



Grizzly プロジェクトより派生した Atmosphere プロジェクトの

初めての成果物 (0.1 GA) がリリースされました。



Atmosphere プロジェクトでは汎用的に使える Comet フレームワークとして

AtmosphereHandler インタフェースを実装して簡単に Comet アプリケーションを

作成することができるようになります。



チャットの実装例



今までは Comet のアプリケーションを作成する場合、サーバ側の実装は

各 Web コンテナの Comet Engine の実装に応じてばらばらに実装しなければ

なりませんでしたが、このフレームワークを利用することで、一度実装した

Comet のサーバ側の実装を様々な Web コンテナ上で動作させることができるようになります。



サポートされる Web コンテナ:
Tomcat,Jetty, GlassFish,Weblogic, Jersey,Grizzly


チャットアプリケーションの実装例:


Getting started with Atmosphere CPR part 1: Writing the HelloWord of Comet….a Chat application



Comet のアプリケーションに興味のある方は是非このフレームワークをお試しください。





ちょっと春らしく:




2009年4月27日 at 1:11 午前

Blocking I/OとNon Blocking I/Oについて



以前、Grizzlyの概要 : C10K問題に対応するGlassFish(Grizzly) というエントリで、

Grizzly が実装している Non Blocking I/O の利点について説明しましたが、

Project Kenai 中のプロジェクト Grizzly-send file 内で過去に書いたエントリの

補足となるような良い説明資料があがっていましたので、こちらでも紹介します。



※ このエントリを読む前に是非、過去の記事をご覧ください。



マルチスレッドで実装された Webサーバ は下記のようにAcceptor スレッドとWorker スレッドの間に

Queueを置いて、処理の効率化をはかっています。






この時、仮に Worker スレッドの数が5個だった場合に8クライアントから同時にファイル取得の

要求が来た場合を想定します。







Blocking I/Oを使って実装されたマルチスレッドサーバの場合、実際に作業ができるWorker スレッドは

5つしかありませんので、3つのクライアントは他の処理が終わるまで Queue で待たなければなりません。

取得する対象のコンテンツサイズが小さい、もしくはすぐに完了するような場合、このBlocking I/O

のマルチスレッドサーバは高速に動作します。



しかし、クライアントからのリクエスト数が膨大になった場合や、取得するコンテンツのサイズが大きい場合、

もしくはコンテンツの取得に時間がかかるような場合、他のクライアントの要求に対して影響が大きいことが

わかります。









一方、Grizzly のように Non Blocking I/O に対応した Web Server を利用すると、Woker スレッドを

効率的に利用することができるようになります。








5つの Woker スレッドが8クライアントからの同時アクセスに対して、各スレッド毎で分割して

処理できますので、誰か1人が大きなファイルを取得したとしても他の人に対して影響は少なく

なります。

そこで、クライアントからのリクエスト数が増えれば増える程、Non Blocking I/Oの実装の恩恵を

受ける事ができます。



PS.

今回は Project Kenai の Grizzly-Send file の画像を使わさせて頂きました。

私が作成した概念図より各スレッド毎に分割されて処理しているのが

分かりやすいので、二つの資料を両方つかうとわかりやすいですね。


2009年4月24日 at 1:03 午前

プロジェクト Kenai について



Project Kenai



オープンソースのプロジェクトを立ち上げたい方

いらっしゃいますか?



自分でプロジェクトを立ち上げた場合、色々な

環境を構築したり管理をしたりしなければなりません。



そのようなオープンソースのプロジェクトを立ち上げるに

あたり必要なリソースを全て利用できるのが、Project Kenaiです。



Project Kenai では下記のようなリソースを提供しています。



 ● ソースコードの管理(Subversion, Mercurial等)

 ● 問題追跡(Jira, Bugzilla等)

 ● Wiki

 ● フォーラム

 ● メーリングリスト

 ● ドキュメントの公開

 ● NetBeansとの統合



このようなリソースをいちいち自分で管理しなくてもよくなるので、

OSSプロジェクトを立ち上げたい方にはとても便利だと思います。



既存のプロジェクトに参加する場合は、サインアップするだけで利用可能です。

また、新しいプロジェクトを立ち上げたい場合はリクエスト

を提出し承認されると利用できるようになります。



※ すでに、US の Sun Developer Network のメンバー登録を行って頂いている方は、

その ID でログインできます。



参考情報:

Project Kenaiについて


NetBeans との統合について


Project Kenai のブログ

Project Kenai Twitter

Project Kenai Facebook



例えば、Grizzly の sendfile の実装もこの Project Kenai の配下で

行われています。



是非、この Project Kenai を有効活用してください。


2009年4月23日 at 10:00 午後

神宮上空のヘリ3台



今日は、神宮のオフィスに出社しているのですが、

昼食時に、ヘリコプターが3台程上空で旋回してました。

何事か?また事件でもあったのか?と思っていたら、

午前中にニュースにあった芸能人さんが原宿署に移送

されたんですね。



この前の爆発もすぐ近くで発生したし、用賀に比べ

この辺りは色々とあるんですねぇ。。。


2009年4月22日 at 10:53 午後

Sun Fire 2270(Intel チップ)で今までの2倍以上のパフォーマンス



Sun Fire X2270Sun FIre 4170 の Intel チップを搭載したH/Wで GlassFish v2.1 と MySQL の

ベンチマークを計測した結果 (2925.18 JOPS) が SPECjAppServer2004 に公開されました。




SPECjAppServer®2004

Sun GlassFish Enterprise Server v2.1 on Sun Fire X2270 with MySQL 5.1 on OpenSolaris 2008.11



これによると、2008年に実施した Sun Fire X4150 の結果 (1,197.10 JOPS)と比べ2倍以上の

結果が得られています。



ベンチマークのシステム構成:










また、先日 GlassFish のハイパフォーマンスを底辺でささえる、Grizzly の新版である Grizzly 2.0.0

マイルストーン1もリリースされたようです。




http://weblogs.java.net/blog/jfarcand/archive/2009/04/grizzly_200m1_r.html


http://blogs.sun.com/oleksiys/entry/grizzly_2_0_m1_release



Grizzly 2.0M1の入手

Grizzly 2.0M1のJavaDoc



Grizzlyについては過去のエントリで紹介していますので、御参考ください。


2009年4月21日 at 7:33 午後

Sun と Oracle について



続々とニュースが出てきていますね。



http://www.sun.com/third-party/global/oracle/

http://www.oracle.com/sun



IT media:Oracle、Sunを買収

CNET Japan: オラクル、サンの買収で最終合意

マイコミジャーナル:【速報】米Oracle、Sun Microsystemsを56億ドルで買収

slashdot: Oracle、Sunを74億ドルで買収



すいません、社員なので公にコメントしたくてもできないので、

本エントリに関してのみ、コメント欄も無効にさせていただいています。


2009年4月20日 at 6:26 午前

GlassFish と Tomcat の違い Part 4



GlassFish と Tomcat の比較について何度か説明してきていますが、
(過去記事)

実際のところ、GlassFish は Tomcat より何が便利なのでしょうか?



今日は、Tomcat ユーザがかかえる問題である「管理の手間について」

管理作業を軽減するために、GlassFish の便利な管理機能について紹介します。



さて、皆様、まず Tomcat でシステムを構築したとしましょう。

この時、サービスが構築時に予想した範囲のアクセス数、処理数で

十分な場合は何も問題がありませんが、サービスが成長してきて

1台のマシンでは処理を裁ききれなくなった場合はどのようにして

システムを拡張していますか?

Tomcat を利用している方は、1台づつマシンにインストールして

1台づつ ログインしては設定を行っていると思います。







設定変更がさほどない環境であればこれでも我慢ができるかもしれません。

しかし、アプリケーションの開発において DB のリソースを追加したいことや、

新しいアプリケーションを追加したい場合も多々あるでしょう。

そのような時、Tomcat では毎回1台づつログインして設定を変更しなければ

なりませんでした。

同じ設定を行うのに1台づつログインして設定して再起動してというような

作業は面倒ではありませんか?

また、作業の数が増えれば増える程、XML ファイルの設定ミス等が発生します。

設定ミス等でアプリケーションが正常に起動しないなんてことで困ったことはありませんか?





GlassFish を利用するとこのような手間と設定ミスのリスクを大幅に軽減してくれます。

インストールは各マシンに行っていただく必要がありますが、リソースの追加や設定変更、

アプリケーションサーバの再起動のために、毎回各システムに対してログインをしなくても済みます。

GlassFish では “ドメイン管理サーバ”(DAS)と呼ばれる1つのアプリケーションから

全てのアプリケーションサーバの設定、たとえばリソースの追加や、起動、停止、

配備、配備取り消し等の操作を行うことができるようになるでしょう。







また、クラスタというアプリケーションサーバのインスタンスの共通グループを

作成する事で、同一クラスタ(グループ)に所属する全てのインスタンスに対して

同一の設定を行いたい場合、たった1回の操作で全てのインスタンスに対して

同じ設定を行うこともできるようになります。

これにより、XMLの編集ミスといった初歩的なミスを大幅に軽減することが

できるようになり、サービスの成長に伴い台数がいくら増えても管理の手間は

増えず、管理時間も大幅に軽減されるようになります。



Tomcat ユーザの皆様?

1台づつログインして設定して、設定をコピー&ペーストして面倒ではありませんか?



中規模から大規模なサービスを展開する場合、この GlassFish が持つ管理機能はとても

便利です。Tomcat の管理で面倒だと感じている管理者の皆様、是非一度

GlassFish を触ってみてください。



設定方法に関する参考資料:

GlassFish のクラスタと負荷分散構成

2009年4月20日 at 2:04 午前

JavaSE6 と GlassFish で JSP の高速コンパイル



皆様、JSR-199 (Java Compiler API)をご存知でしょうか?



Java SE 6 で拡張された機能の一つなのですが、この API を

利用すると、Java のプログラム中から Java のソースコードを

コンパイルできるようになります。

一見すると、この機能と GlassFish どのような関連があるの?

と思われる方もいらっしゃるかと思いますが、JSR-199 に対応した

JSP コンパイラが GlassFish 上で実装されています。



そこで、JSP/JSF 等のコンパイルが非常に高速になります。

(一説によると3.5倍〜10倍早いとか)

今までは、JSP をコンパイルした後、Servletコードをファイルに

出力してロードしてとアプリケーションの起動までに結構時間が掛かった

りしましたが、GlassFish ではファイルに書き出さず直接メモり上で

コンパイル等の動作を行うことができます。



ですので、

GlassFish は Java SE 6 で動かすことをおすすめ致します。Java SE 5 を

ご使用中の方は、バージョンを変更したい場合、下記のファイルを修正し

変更してください。





# vi glassfish-v2.1/config/asenv.conf

AS_JAVA=”/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home”




また、開発者の方は、上の説明でではコンパイルされたコードを

見たい場合はどうすればいいのだろう?と思う方もいらっしゃると思います。

NetBeans をご使用されている方は、Web のプロジェクトを作成した際に

デフォルトでソースコードが出力される設定が追加されています。



具体的には、プロジェクト中の設定ファイル(sun-web.xml) に

下記の行が追加されています。





<jsp-config>

<property name=”keepgenerated” value=”true”>

<description>Keep a copy of the generated servlet class’ java code.</description>

</property>

</jsp-config>




開発者の方はこれを消していただくことで、Java のコードは出力されなくなり

全てメモり上で作業が行われますので下記を消して再度配備してみてください。

逆に言うならば、NetBeans 等をご利用されていない場合は、上記のコードを

記載していない場合、Java のコードは出力されませんのでご注意ください。





ちなみに、Java のソースコードの出力先は下記になります。




glassfish-v2.1/domains/domain2/generated/jsp/j2ee-modules/APPLI_NAME/org/apache/jsp




効果の程は、是非皆様ご自身の手で試してみてください。



参考資料の抜粋:


http://blogs.sun.com/kchung/entry/speed_up_jsp_compilations_with





The performance gain for using JSR1 199 API is amazing! Preliminary measurement shows an order of magnitude improvement in raw Javac compilation speed, and a 3.5X improvement in overall execution when running JSP TCK tests!





https://glassfish.dev.java.net/ja/public/WP_GlassFish_Overview.pdf





GlassFish のもう 1 つの注目すべき変更点は、Java コンパイラの Jasper が Java SE 6
のコンパイラ API (JSR-199) を利用できるようになり、ファイル IO の回避とコンパ
イル速度の大幅な向上 (非公式の計測では約 10 倍の高速化) が実現されたことで
す。JSR-199 を使用する場合ほど高速ではありませんが、Eclipse JDT コンパイラを
使用するように Jasper を構成することもできます。残念なことに今は手元にベン
チマーク結果がないのですが、JSF 実装も大幅に改善されました。




2009年4月10日 at 2:18 午前

週末の散歩シリーズ



今週末は中目黒、芝公園辺りを散歩してきました。












2009年4月6日 at 1:45 午前

GlassFish v3 のスケジュール公開



GlassFish v3 のスケジュールがドラフトとして公開されたようです。



GlassFish v3 リリーススケジュール


ここ最近の私のプレゼンを聞いてくださった方にはリリースが遅れるかもしれない

ことを伝えておりましたが、上記でスケジュールドラフトが公開されたようです。



当初、GlassFish v3 は今年の JavaOne でリリース予定でした。

しかし Java EE 6 の仕様策定が今年までずれ込んだため

(本来は仕様は昨年末に FIX 予定でした)

Java EE 6 の参照実装である GlassFish v3 の開発スケジュールもリスケされ、

結果として今年の秋のリリースとなる予定です。



GlassFish v3.0 は Java EE 6 の参照実装を公開するという意味合いが強く、

エンタープライズ環境で必要なクラスタなどの管理機能が

含まれていません。

そこで、GlassFish v3.0 は開発者の皆様が Java EE 6 の開発に

なじんで頂くための製品としてとらえて頂ければと思います。



エンタープライズ環境でクラスタ等の機能が利用できるように

なるのは GlassFish v3.1 になってからになります。

GlassFish v3.1 のリリースは恐らく2010年以降になるかと思いますので

それまでは、現在の GlassFish v2.1 を本番環境でご使用頂ければと思います。



また、既存の GlassFish v2 のユーザには一つだけ残念なお知らせがあります。

GlassFish v3 は新しいアーキテクチャ(OSGi対応)となるために、

既存の GlassFish v2.x ユーザはアップグレード時に少しだけ

手間を掛けていただく必要があります。(2009年4月時点の方針)



今まで、Sun のアプリケーションサーバ (Sun Java System Application Server )を

使って頂いていた方は、GlassFish Enterprise Server のインストール時に既存の

インストールパスを指定すれば既存の、アプリケーションや設定等をそのまま自動的に

アップグレードしGlassFish 環境で動作させることが可能でしたが、GlassFish v2 から

GlassFish v3へはインストール時にそのような自動アップグレード機能が存在しません。



GlassFish v2 から GlassFish v3 へは手動で設定してアップデートしていただくか、

もしくはかんたんにアップデートできるようなツールが用意されるかと思いますが、

今までよりもインストール時のアップグレードに対して若干手間が掛かってしまいます。

アーキテクチャの大幅な変更のため、どうぞご理解頂ければと思います。

(まだ、開発中の製品ですので今後方針が変わる可能性もあります。

 また、もちろん新規構築のシステムであればインストールや導入も非常にかんたんです。)



しかし、そのような手間が掛かったとしても、GlassFish v3 になると OSGi 対応、

モジュール化の恩恵が多いに受けられると思いますので、どうぞ楽しみにしてください。



GlassFish v3 は Java EE 6 の参照実装として位置づけられた製品ですが、

Java EE を動かすためだけのサーバではありません。

JRuby がネィティブで動作したり、EJB が必要なければ使わなくてもすむというような

ユーザのニーズに柔軟にこたえることができる、サーバに生まれ変わります。

(起動時間もたった数秒です。)



今まで、アプリケーションサーバは重たいし EJB が必要ないから Tomcat で十分と

思っていらっしゃる方も多いかと思います。

GlassFish v3 はアプリケーションサーバの常識が変わります。

是非、GlassFish v3 に期待していてください。


2009年4月2日 at 7:37 午後


Java Champion & Evangelist

Translate

ご注意

このエントリは個人の見解であり、所属する会社の公式見解ではありません

カレンダー

2009年4月
 12345
6789101112
13141516171819
20212223242526
27282930  

カテゴリー

clustermap

ブログ統計情報

  • 1,299,718 hits

Feeds

アーカイブ