1 / 25

Grizzly フレームワーク Non-Blocking ソケットと非同期処理に対応した HTTP 等プロトコルハンドラフレームワーク

Grizzly フレームワーク Non-Blocking ソケットと非同期処理に対応した HTTP 等プロトコルハンドラフレームワーク. Learning.sandbox.seasar.org 2006-12-27 栗原 傑享. About Grizzly - とりまく環境 -. GlassFish の傘下コンポーネント 内包される Web コンテナの部品 プロトコルハンドラを作るための F/W NIO の Non-Blocking ソケットを活用する F/W 最近、 java.net のトッププロジェクトへ

sheri
Télécharger la présentation

Grizzly フレームワーク Non-Blocking ソケットと非同期処理に対応した HTTP 等プロトコルハンドラフレームワーク

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GrizzlyフレームワークNon-Blockingソケットと非同期処理に対応したHTTP等プロトコルハンドラフレームワークGrizzlyフレームワークNon-Blockingソケットと非同期処理に対応したHTTP等プロトコルハンドラフレームワーク Learning.sandbox.seasar.org 2006-12-27 栗原 傑享

  2. About Grizzly - とりまく環境 - • GlassFishの傘下コンポーネント • 内包されるWebコンテナの部品 • プロトコルハンドラを作るためのF/W • NIOのNon-Blockingソケットを活用するF/W • 最近、java.netのトッププロジェクトへ • https://grizzly.dev.java.net/ • Grizzlyが採用されているOSSプロダクト • Jetty6.1 • http://www.mortbay.org/ • AsyncWeb • http://docs.safehaus.org/display/ASYNCWEB/Home • JRuby on Rails • われらが、高井さんのプロジェクト。この先Grizzlyに同梱？

  3. About Grizzly - 守備範囲 - • Non-Blockingソケット通信 • Java NIOにて提供されるNon-Blockingソケット（以後、NBソケット）通信をフレームワーク化して容易に用いることができるようにしている。 • 非同期処理 • Ajaxや昨今のWeb2.0的アプリケーションで求められる、超長期トランザクションにNBソケット通信でも対応できる機能をフレームワーク上に応用実装した。 • さらに、Ajax/Cometの機能をデフォルト提供 • デフォルトHTTP機能 • Grizzlyは専らHTTPのハンドラとして機能が設計、提供されている。 • 2.0計画の中では、ESBエンジンの実装基盤など、非HTTPもしくはHTTPからさらに発展した今後、汎用のプロトコル通信フレームワークとして発展させていく野心があるように、説明されている。

  4. Blockingソケット • NIO以前 • Java.netパッケージのAPIを利用 • Servletコンテナの価値 = このコーディングを隠蔽 スレッド ServerSocket server = new ServerSocket(8080); Socket con = server.accept(); InputStream in = con.getInputStream(); for(int b = in.read(); b != -1; b = in.read()) { // 読み込み } // ロジック実行（Servletの実行など） OutputStream out = con.getOutputStream(); for(int b = /* 書き出しバイトのバッファ */ ) { out.write(b); } サーバソケットOpen 接続 Accept Blocking リクエストRead Blocking ロジック実行 レスポンスWrite Blocking 接続 Close 例外処理、コネクションCloseなど省略

  5. Non-Blockingソケット - ソース - ServerSocketChannel channel = ServerSocketChannel.open(); channel.socket().bind(new InetSocketAddress(8080)); Selector selector = Selector.open(); channel.register(selector, SelectionKey.OP_ACCEPT); while(selector.select() > 0) { for(Iterator<SelectionKey> it = selector.selectedKeys().iterator; it.hasNext(); ) { SelectionKey key = it.next(); it.remove(); if(key.isAcceptable()) { SocketChannel socket = channel.accept(); socket.register(selector, SelectionKey.OP_READ); } else { if(key.isReadable()) { /* 読み込み */ } if(key.isWritable()) { /* ロジック実行、書き出し */ } } } } コード例は不完全で、実際に動かすためにはほぼ倍以上の実装量が必要 例外処理、コネクションCloseなど省略

  6. Non-Blockingソケット 省略のためUMLを故意に誤用 ServerSocket Channel Socket Channel Selector アプリ スレッド チャネルBIND 初期化 クライアント から接続 登録（ON_ACCEPT） SelectionKeyに結びつく Acceptableに設定 isAcceptable ？ Yes！ Accept処理 ループ selectを繰り返す SocketChannel取得 クライアント からリクエスト受信 登録（ON_READ） SelectionKeyに結びつく Readableに設定 Writableに設定 isReadable ？ Yes！ 読み込み isWriable ？ Yes！ 書き込み クライアントへ

  7. スレッドに優しい仕組み • NBソケット • スレッドの占有の問題を解決する • ソケット接続を維持（OS機能）、スレッドは適宜解放 • OS機能に「待ちうけ時間」は負担してもらう • 結果、接続数あたりのスレッドの消費が少ない • リスク • 実装が複雑になること -> Grizzlyで解決。 • スケーラビリティをアプリケーション外部（クラスタリングなど）で確保するのであれば、Blockingのほうが単純なので早いものが作れる

  8. No Apache • http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html • But as other Java based HTTP Connector, scalability is always limited to the number of available threads, and when keep-alive is required, suffer the one thread per connection paradigm. Because of this, scalability is most of the time limited by the platform's maximum thread number. To solve this problem, people usually put Apache in front of Java, or use a cluster to distribute requests among multiple Java server. • 前後の事情も込みで意訳 • （Grizzlyがベースとして採用しているTomcat Coyoteも含めた従来の）JavaベースHTTPコネクタは、スケーラビリティは常に利用可能スレッド数に制限されています。keep-aliveでリクエストされた時は長い接続単位あたりそれぞれにずーっと1スレッドが費やされ続けます。そのため、スケーラビリティは多くの場合プラットフォームの最大スレッド数に制限されます。この問題を解決するために、普通みんなはApache HTTPDをJavaシステムの前に置いたり、たくさんのJavaアプリケーションサーバをクラスタしてますね。（これは大変な苦労です。） • Grizzlyにより、Apache無しのJavaシステムでOKになる。

  9. Simple Grizzly package org.ashikunep.iyomante; import com.sun.enterprise.web.connector.grizzly.SelectorThread; import com.sun.enterprise.web.connector.grizzly. standalone.StaticResourcesAdapter; import org.apache.coyote.Adapter; publicclass SimpleGrizzly { publicstaticvoid main(String[] args) throws Exception { SelectorThread selectorThread = new SelectorThread(); selectorThread.setPort(8080); Adapter adapter = new StaticResourcesAdapter(); selectorThread.setAdapter(adapter); selectorThread.initEndpoint(); selectorThread.startEndpoint(); } } Tomcat Coyote のクラス このAdapterを作って設定するのが、想定されているGrizzlyアプリケーションの開発方法。 ここで用いているものは、静的なファイルを読み出して返すもの。 これだけで、最低限の機能ながらちゃんと動く

  10. 参考： Adapter インターフェイス package org.apache.coyote; publicinterface Adapter { void service(Request req, Response res) throws Exception; void afterService(Request req, Response res) throws Exception; void fireAdapterEvent(String type, Object data); } package org.apache.coyote; publicfinal class Request { public Response getResponse () { returnresponse; } … } package org.apache.coyote; publicfinal class Response { public void doWrite(ByteChunk c) { … } … }

  11. Grizzlyの構造 SelectorThread ON_ACCEPT クライアント から接続 Socket Channel Selector (ACCEPT用) ON_READ Stream Algorism Pipeline (Read用) ReadTask Pipeline (Process用) ProcessorTask Adapter ユーザー アダプター ごめんなさい、書きかけです。 登場人物が多すぎ

  12. Grizzlyのアーキテクチャ - 用語 - • SelectorThread • NBソケット処理のメインスレッドを隠蔽 • nio.Selector、Pipelineを複数もつ • （Pipeline） • Taskを単位として管理するスレッドプール • Task • ソケットに対する処理を分割した単位 • （ReadTask） • ON_READに対する処理、SlectorThreadより実行される • ProcessorTask • ON_WRITEに対する処理、ReadTaskより実行される • Adapter （Tomcat Coyoteより） • ProcessorTaskより実行される • （Handler） • Grizzlyへの高度なカスタマイズを行うイベントハンドラ • 今のところ、Coyoteとの接続やAsyncの実装に使われるのみで、拡張ポイントとしてはあまり活用されていない。

  13. Grizzlyのアーキテクチャ - 逆引き - • 接続処理 • SelectorThread#startEndpoint()で開始 • クライアントからの接続要求に応答 • 読み込み処理 • ReadTaskインターフェイスを実装する • クライアントから到着するリクエスト電文を読む。 • ビジネスロジック＆書き込み処理 • ProcessorTaskインターフェイスを実装 • もしくは、coyote.Adapterを実装。 • リクエスト電文に応じて処理を行う。DBアクセスしたり、画面遷移したり、応答書き出しをすいる。

  14. SSL対応 • 使ってる例が見当たりません • JettyもGrizzlyのSSL機能を使ってない？ • AsyncWebもGrizzlyのSSL機能を使ってない？ • コードを読むと • SelectorThreadの代わりにSSLSelectorThreadを利用するだけのハズ。。。しかし動かない。。。 • ということで、いつかどこかでの、宿題。 • たぶん、WEBコンテナを作るために必要なので近日に解明するでしょう。

  15. 非同期処理 • NBソケットは単一もしくは少数スレッドで多数の接続を処理する。 • 読み込み、書き込みともに（大抵は）同一スレッドで多数の接続を処理 • ロジック実行に長時間が経過するアプリケーションだと、この超ロングトランザクションによってスレッドがいわば「Blocking」されてしまう • Task処理をマルチスレッドで実行する • 特にProcessorTaskの処理 • このあたりの技術をひとまとめに、Grizzlyでは「Asynchronous Request Processing（ARP）」と呼ぶ。 • 基本的に、ここに踏み込むことはあまりない。 • Cometの実装など、プロトコル処理の根底に関わる仕組みで、かつ非同期実行がその解決策であるときに利用

  16. ARP • 新たに、登場人物 • AsyncFilter, AsyncHandler, AsyncExecutor SelectorThread st = new SelectorThread(); st.setPort(8080); st.setAdaptor(new StaticResourcesAdapter()); AsyncHandler handler = new DefaultAsyncHandler(); handler.addAsyncFilter(new AsyncFilterImpl()); st.setAsyncHandler(handler); st.setEnableAsyncExecution(true); st.initEndpoint(); st.startEndpoint(); class AsyncFilterImpl implementsAsyncFilter { public boolean doFilter(AsyncExecutor executor) { … return false; } } ここで何をやるのかが、大抵ネタが無い。必要なモノはAsyncExecutorが実行時コンテキストとしていろんなものを提供してくれているので、それを使ってプログラミング

  17. Comet • Cometとは • CNetの江島氏のBLOGに詳しい • http://blog.japan.cnet.com/kenn/archives/003149.html • サーバからクライアントへの通信をリアルタイムに行って、情報を擬似的にプッシュを実現する • KeepAllive=trueでつなぎっぱなしの仕組み • スレッドが爆裂する問題にどう取り組むか？その答えがNBソケット • GrizzlyではComet対応が標準組み込み １）と6)の間には長い時間経過を許す。２）による書き込みがなければ、ずっとつなぎっぱなしで待機。 http://www.machu.jp/diary/20060411.htmlより図を引用

  18. まとめ • Grizzlyはプロトコルハンドラをつくるためのフレームワークである • 特別踏み込まなければ驚くほど簡単 • NIOのNBソケットをゼロから使って同様なものを作ってもいい、しかしいろいろ嵌るのでGrizzlyを使うと吉 • 基本的なNBソケットによるHTTPハンドラに加え、SSL対応、非同期処理、Cometエンジンがそれぞれ標準で組み込まれている

  19. 今回触れなかったもの その1 • 今回触れなかった、2つのパッケージ • com.sun.enterprise.web.ara • com.sun.enterprise.web.portunif • ARA • Grizzly’s Application Resources Allocation • RCMの実装、JSR284にて作業中のものを意識 • Resource Consumption Management • Googleのリードで、2006年12月18日にパブリックレビュー終了したところ。これからファイナルドラフトへ • あらゆるJavaアプリケーションで扱う「リソース」を管理する仕組み。Grizzlyではスレッドとメモリに注目。 • ルールベースによるReadタスクの分散技術？

  20. 今回触れなかったもの その2 • 今回触れなかった、2つのパッケージ • com.sun.enterprise.web.ara • com.sun.enterprise.web.portunif • PortUnif • TCPソケットの送信バイトをちょっと見て、プロトコルの種類を識別する仕組み？単一ポートで複数プロトコルを取り扱うことが狙いのようである。HTTPとHTTPSを扱うものが同梱されている SelectorThread st = new SelectorThread(); st.setPipelineClassName(PortUnificationPipeline.class.getName()); … st.initPipeline(); PortUnificationPipeline pup = (PortUnificationPipeline)st.getReadPipeline(); pup.addProtocolFinder(…); pup.addProtocolHandler(…);

  21. 今回説明できなかったこと • SSLを利用したGrizzlyアプリケーション • 時間作って、GlassFishのコードを読んでみます • ARP、Cometの具体的動き • これは理解＆ちゃんと動作済み。しかし当面取り組むネタが無い。可能性を考察していきましょう。 • 整理： • ビジネスロジックを実行するのに、時間がかかるとき有効な仕組み • NBソケットは基本的にシングルスレッドの下で動くので、これをちゃんとやらないと全体速度に関わる • Cometは今、ホットな話題だそうです。手軽にはCometdやJetty6で試すことができます。

  22. Grizzlyに無いもの • WEBコンテナを作る上でGrizzlyに無いもの • そもそも：WEBコンテナ仕様 • ブートストラップ • アプリケーションコンテナ • 仮想化されたファイルシステム • セッションマネジメント • クラスタリング • 認証関連 • Grizzlyにあるけど作りたくなるもの • リクエストパーサ、レスポンスアウトプッター • ログ出力 • JMX対応等、管理関連 （JMX、あるのです！）

  23. 参考資料 • 開発者：Jean-Francois ArcandのBlog • http://weblogs.java.net/blog/jfarcand/ • GrizzlyおよびNIOの高度な話題、しかし更新頻度が低い。 • JavaOne2005/2006プレゼンテーション • http://72.5.124.65/learning/javaoneonline/2005/webtier/TS-3227.pdf • http://weblogs.java.net/blog/jfarcand/archive/2006_BOF0520.pdf • Grizzlyソース • ほか、AsyncWebやJettyソースのごく一部 • NIOによるNon-Blockingソケット通信 • 「ServerSocketChannel」「Selector」「SelectionKey」などで検索すると結構たくさん出てくる。しかし、ほぼ初級な話題。

  24. おまけ

  25. フレームワークの限界 • 最近の私の主張 • いろいろありますが、アプリケーションに近いF/Wだけでなんとかできることも減ってきてるでしょ？（以下略） • バカ対策F/Wを否定するのであれば、その解決策を模索していかなければならない • 私の考える二つの方向性へのヒント • WEBコンテナなど、アプリケーションのブートストラップからの見直し -> Grizzlyの出番もあるか？Kvasir？ • EclipseプラグインなどのIDEだけに止まらない、開発環境アプリケーションの創造 • しばらく具体的な話は蒸発する状態でのみします • ほら、世間って怖いしw。。。ということで今日、放談。 • 具体的なアプリケーションを見せないと、机上の空論だし

More Related