Play 2.0 コードリーディング - リクエストを受ける(前)
一人Play 2.0 コードリーディングの第二弾です。
今回はリクエストを受けとった時にどのような処理をするかを追ってみました。
そもそも発端はPlay2.0ではリクエストをどのように処理させているのか気になり、
意図的に例外を発生させてみました。
すると、出力されたスタックトレースは以下のようなものだったのです。
play.core.ActionInvoker$$anonfun$receive$1$$anon$1: Execution exception [[Exception: null]] at play.core.ActionInvoker$$anonfun$receive$1.apply( ... at play.core.ActionInvoker$$anonfun$receive$1.apply( ... at akka.actor.Actor$class.apply( ... at play.core.ActionInvoker.apply( ... at akka.actor.ActorCell.invoke( ... at akka.dispatch.Mailbox.processMailbox( ... Caused by: java.lang.Exception: null at controllers.Application$$anonfun$index$1.apply( ... at controllers.Application$$anonfun$index$1.apply( ... at play.api.mvc.Action$$anonfun$apply$4.apply( ... at play.api.mvc.Action$$anonfun$apply$4.apply( ... at play.api.mvc.Action$$anon$1.apply( ... at play.core.ActionInvoker$$anonfun$receive$1$$anonfun$4.ap ...
大本がakka.dispatch.Mailbox.processMailboxになっており、
Play2.0本体のスタックがほとんど出力されていません。
こりゃどういうことだ?と気になってソースを追ったのがこのエントリーです。
結論的を先に書いてしまうと、
Play2.0は以下の流れでリクエストを処理していました。
- リクエストを受けとるとNettyの仕組みを使って play.core.server.netty.PlayDefaultUpstreamHandlerがハンドリングする
- play.core.Serverを経由してplay.core.Router.RoutesがActionを決定する
- AkkaにActionを実行する為のメッセージが登録される
- AkkaからActionを実行する
これらの処理を順を追って説明したいと思います。
大半は自分のためのメモのため、ダラダラと長くなってしまったので前後編に分けます。
さて、Play2.0は内部的にはNettyを使用して動いています。
Play2.0自体はNettyのラッパーと言っても過言ではありません。
そのため、リクエストを受けとるとorg.jboss.netty.channel.SimpleChannelUpstreamHandlerのサブクラスでハンドリングします。
つまりそれは、play.core.server.netty.PlayDefaultUpstreamHandlerのことです。
リクエストを受けとるとPlayDefaultUpstreamHandlerのmessageReceivedメソッドが実行されます。
private[server] class PlayDefaultUpstreamHandler(server: Server, allChannels: DefaultChannelGroup) extends SimpleChannelUpstreamHandler with Helpers with WebSocketHandler with RequestBodyHandler { // Play2.0本体で、リクエストを受けとった時に一番最初に実行されるメソッド override def messageReceived( ctx: ChannelHandlerContext, e: MessageEvent) { e.getMessage match { case nettyHttpRequest: HttpRequest => { val keepAlive = isKeepAlive(nettyHttpRequest) val websocketableRequest = websocketable(nettyHttpRequest) var version = nettyHttpRequest.getProtocolVersion val nettyUri = new QueryStringDecoder(nettyHttpRequest.getUri) val parameters = Map.empty[String, Seq[String]] ++ nettyUri.getParameters.asScala.mapValues(_.asScala) ... // Actionの取得 val handler = server.getHandlerFor(requestHeader)
messageReceivedではリクエストヘッダーの解析等を行なった後、
server.getHandlerForでActionを取得する処理が行なわれます。
serverのクラスはplay.core.server.NettyServerクラスで、
getHandlerForの返り値の型はEither[Result, (Handler, Application)]です。
つまり、正常にActionが決定した場合rightでHandlerとApplicationのタプルを、
エラーが発生した場合はleftでResultを返すということです。
HandlerはActionがmix-inしているトレイトでメンバーを一切もたない、
マーカーの為の型です。
続いてgetHandleForの中身も見てみます。getHandleForの定義はplay.core.server.Serverトレイトにあります。
def getHandlerFor(request: RequestHeader): Either[Result, (Handler, Application)] = { def sendHandler: Either[Throwable, (Handler, Application)] = { applicationProvider.get.right.map { application => val maybeAction = application.global.onRouteRequest(request) // Actionが見つからなかった場合はNotFound用のHandlerを返す。 ( maybeAction.getOrElse( Action(BodyParsers.parse.empty) (_ => application.global.onHandlerNotFound(request))), application ) } def logExceptionAndGetResult(e: Throwable) = { // エラー発生時のハンドリング DefaultGlobal.onError(request, e) } sendHandler.left.map(logExceptionAndGetResult) }
getHandlerForのポイントは以下の三つです。
- play.core.ApplicationProviderからApplicationを取得しています。
- Actionの取得処理をapplication.global.onRouteRequest()に移譲しています。
- エラーのハンドリングをgetHandlerForで行なっています。Actionが見付からなかった場合はNotFoundを返すHandlerを返し、途中で例外が発生した場合はDefaultGlobal.onErrorを使ってInternalServerErrorのResultを返します。
applicationProviderの実際の型はPlayを実行しているコンテキストから、以下の三つのサブクラスの中から一つが選ばれます。
- StaticApplication - 本番稼動などで使用するApplicationProvider
- TestApplication - テスト用のApplicationProvider
- ReloadableApplication - Dev Mode用のリロードが出来るApplicationProvider
application.global.onRouteRequestではconfig/routesをもとに、
実際にActionを取得する処理を行なっていますが、続きは後編で解説します。