Play frameworkのpidファイル「RUNNING_PID」ファイルの場所を変える(v2.0.4以降)

Play frameworkを本番環境にデプロイする場合に、PIDファイルを別の場所に置きたいなと思ったりします。

デフォルトだとプロジェクトディレクトリの直下にRUNNING_PIDというファイルが作成されます。

このRUNNING_PIDファイルを作る所のコードを確認すると

play.core.server.NettyServer

の中にあるようです。

[scala]
def createServer(applicationPath: File): Option[NettyServer] = {
// Manage RUNNING_PID file
java.lang.management.ManagementFactory.getRuntimeMXBean.getName.split(‘@’).headOption.map { pid =>
val pidFile = Option(System.getProperty("pidfile.path")).map(new File(_)).getOrElse(new File(applicationPath.getAbsolutePath, "RUNNING_PID"))

// The Logger is not initialized yet, we print the Process ID on STDOUT
println("Play server process ID is " + pid)

if (pidFile.getAbsolutePath != "/dev/null") {
if (pidFile.exists) {
println("This application is already running (Or delete "+ pidFile.getAbsolutePath +" file).")
System.exit(-1)
}

new FileOutputStream(pidFile).write(pid.getBytes)
Runtime.getRuntime.addShutdownHook(new Thread {
override def run {
pidFile.delete()
}
})
}
}
}
[/scala]

PIDファイルの場所をカスタマイズするには、pidfile.pathというオプションにPIDファイルのパスを指定すれば良いようです。

ということで、プロジェクトの起動パラメータとして
[text]-Dpidfile.path=/tmp/hogeproj.pid[/text]
という感じに指定します。

Play Framework 2.0でログファイルローテートしてみる

Play Framework 2.0系のプロジェクトで、リクエスト毎にログを出力するような設定をした場合、ログファイルをローテートしたくなったりします。

場合によってはlogrotateの設定でやったりもします。

が、今回は、Play Frameworkのログの設定でローテートしてみます。

Play Frameworkは、LogBackというミドルウェアを使用してログを出力します。

で、必要な設定などはすでにPlay Framework自体が設定してくれているので

ログを出力するのは

[text]
Logger.debug("debug ok")
[/text]

という感じでログが出力出来ます。

ログはデフォルトでは
{プロジェクト}/logs/application.log
に出力されます。

デフォルトではログファイルはローテートしないので、カスタマイズして見ます。

カスタマイズするには

logger.xml(ファイル名は適当)というファイルをconf配下に作成します。

Play Framework本体からlogger.xmlファイルをコピーして持ってくるのが確実かもしれません。

その場合は、
{Play Framework}/framework/src/play/src/main/resources/logger.xml
をコピーして持ってきます。

application.logに出力する設定は、

[text]
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
[/text]

という部分になります。 LogBackの設定で、ローテートさせる設定はというと、 このclassの部分を「ch.qos.logback.core.rolling.RollingFileAppender」に変える事で対応出来るようなので、変更します。 さらに、ローテートする条件と、ローテート時のログファイル名をappenderのメンバーとして以下のように指定します。

[xml]
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${application.home}/logs/application.%d{yyyy-MM-dd}.log</fileNamePattern>
<maxHistory>10</maxHistory>
</rollingPolicy>
[/xml]

fileNamePatternは、ローテート時のログファイル名
maxHistoryは、ヒストリ保持期間(日)

となります。

これで設定ファイルは完成しました。

続いて、このログの設定ファイルを起動時に読み込む設定ですが、これは起動時のパラメータになります。

startコマンドでやる場合は

[shell]
play "start -Dlogger.resource=logger.xml"
[/shell]

となります。

target/startの場合は

[shell]
target/start -Dlogger.resource=logger.xml
[/shell]

となります。

今回はapplication.logという名前のままでしたが、本番用と開発用でログファイル名を分けるのも良いかもしれません。

Play Framework で、リクエストログを出力したい

リクエストを受けた直後のアクションについては

/app/Global.scala

というオブジェクトのファイルを作り

GlobalSettingsを継承します。

このGlobalSettingsというトレイトには

beforeStart
onStart
onStop
onRouteRequest
onError
onHandlerNotFound
onBadRequest

というメソッドが定義されていて、それぞれオーバーライドする事でアクションを設定する事が出来ます。

今回は、リクエストが来た時に処理させたいので
onRouteRequest
をオーバーライドして使います。

[scala]
import play.api._
import play.api.mvc._

object Global extends GlobalSettings {
/**
* リクエストが発生した時に実行される処理
*
* オーバーライドして、ログ出力後に親メソッド起動
*/
override def onRouteRequest(request: RequestHeader): Option[Handler] = {
Logger.info(request.toString)
super.onRouteRequest(request)
}
}
[/scala]

このように設定する事で、リクエストがあるたびにリクエスト情報を常にログに出力することが出来ます。

Play Framework で、SQLの実行ログもログに出力させたい場合

Play Frameworkはなんか、デフォルトで正常に動いていると、ログが少ないなと思ったりします。

正常に動いたように見えても、データがおかしいのを拾っている場合もあります。

そんな時は、どんなSQLが叩かれているのかと言うのを見たくなります。

Ruby on Railsでは、developmentモードで起動していると常にSQLの実行ログが出たりしますが

Play Frameworkでは設定を追加しないと駄目なようです。

設定は

application.conf

db関係の設定があると思うのですが
その設定と同列の設定で

[text]db.default.logStatements=true[/text]

というのを1行追加します。

さらに、

[text]# Root logger:
logger.root=ERROR[/text]

という部分を

[text]logger.root=DEBUG[/text]

に変更します。

これで、コンソールにログが出力されるようになります。

Play Framework 2.0.2 で負荷をかけるとエラーが出まくる

これは、Play Framework で使用しているAkkaのデフォルト設定による物で、ボディパーサのタイムアウトが1秒に設定されています。

retrieveBodyParserTimeout = 1 second

なので、負荷をかけていって、一つのリクエストが1秒を超えたあたりでタイムアウトのエラーが発生してしまいます。

そこで、Akkaの設定を追加してあげれば良いのですが、どこに追加したら良いかというと

決まりは無い感じですが

confの中にあるapplication.confとか
akka.confを作ってapplication.confincludeするかとかです。

今回は適当にapplication.confの一番下に付けちゃいます。
[text]play {
akka {
event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
loglevel = WARNING

actor {
deployment {
/actions {
router = round-robin
<span style="color: #ff0000;">nr-of-instances = 128</span>
}

/promises {
router = round-robin
nr-of-instances = 24
}

}

<span style="color: #ff0000;">retrieveBodyParserTimeout = 120 second</span>

actions-dispatcher = {
fork-join-executor {
<span style="color: #ff0000;">parallelism-factor = 100</span>
<span style="color: #ff0000;">parallelism-max = 512</span>
}
}

promises-dispatcher = {
fork-join-executor {
parallelism-factor = 1.0
parallelism-max = 24
}
}

websockets-dispatcher = {
fork-join-executor {
parallelism-factor = 1.0
parallelism-max = 24
}
}

default-dispatcher = {
fork-join-executor {
parallelism-factor = 1.0
parallelism-max = 24
}
}

}
}
}[/text]
適当にretrieveBodyParserTimeoutですが、適当に120秒と指定してみました。

長すぎですね。。

続いて、負荷をかけていくと、まだCPU、メモリ共にマシンに余裕がありそうな感じなので

Play Frameworkの処理スレッド数を増やしてみました。

actions-dispatcherという所の
parallelism-factorを100に
parallelism-maxを512に
設定してみました。

factorの方は、マシンのCPU数×factorの数値分スレッドを増やしますよ、という設定らしく、これも大きすぎですね。まぁいいや。

で、maxの方は、action-dispatcherでは、最大スレッド数をmaxの値までに制限しますよ、という事らしいです。
ようするに、512スレッドまでしか増えないという感じでしょうか。

スレッド数、いくつがちょうど良いんでしょうね。
環境毎に試行錯誤が必要な気がします。

それにしても、まだCPUには余裕があるのは何故なんだ。。

もう少しくらい負荷がかかっても余裕なのに。。

Play Frameworkでapplication.confではなく、別の設定ファイルを読み込んで起動する設定

application.confには前環境で共通の内容を設定
prod.confには、本番環境用のみのものを設定

という感じで、本番と開発で設定を分けたいなと思います。

これを実現するには

起動時のパラメータに以下のような設定を追加することで実現出来ます。
[text]config.resource=prod.conf[/text]
このconfig.resourceというのは、Play プロジェクト内のリソースとしてのprod.confを読み込みます、という設定なので、
confディレクトリに格納しておく必要があります。

confディレクトリに捕らわれずに別の場所に置きたいという場合は

config.fileにすればフルパスで設定することが出来ます。

[Scala]Play framework 2.0 のwithSessionを使うと今まで入れてたセッションが消える

APIDOCとか、Documentをみたら、分かる事ではあるが、はまりやすいので書いておく

とした場合に

action1を叩いてからaction2を叩くと
セッションの情報がtest2 -> value2だけになる。

test1とtest2のセッションを保持したいなら

とする

たぶん

[Scala]Play framework で使用するJVMのヒープサイズを環境変数で指定する

Scalaの開発をVMで行っているわけでありますが

素のPlay frameworkだと、色々やってるうちにメモリを浪費してしまうようです。

メモリリークでは無いけど、必要なメモリをどんどん確保してしまうみたい。

なので、ヒープの上限という意味で割り当てを指定してみます。

毎回Play起動時に指定するのは面倒なので、環境変数で。

#~/.bashrc を開いて、一番下あたりに

と書き込んでターミナルを再起動します。

以上です。

playを起動すると

Picked up _JAVA_OPTIONS: -Xms256M -Xmx256M
という行がコンソールに出てきたと思います。

[Scala]Play framework 2.0で、playのコンソールに入らずにアプリを実行する

Play frameworkは便利ですが、そのまま稼働させたい時などにわざわざ

なんて打ちたくありません。

でも、playコマンドにそのままstartと引数を付けて叩くと、コマンド一発で起動する事が出来ます。

ところが、

なんてやった場合に、ポートが80番にならない。

よくよく調べてみると、playコマンドに対してstartと80の引数が渡された状態のようで

playはstartだけを有効な引数として見るっぽいです

なので、

playに渡す引数は一つにする必要があって

とやって上げる事で

“start 80”

と認識してくれます。

[Scala]Ubuntu11.xx上でPlay framework 2.0 for Scalaで、ImageMagick/jMagickを使ってみる

Ubuntu 11.xx上で、Play framework 2.0 for ScalaからImageMagickを使う

ということで、今回のコンセプトですが

cookpadにはtohuがある

ぼくらにはない

でもapacheのモジュールで作るのもしんどい

という事で、Play framework for Scalaで作るという事なのです

まずはJDKのインストール

これは、

http://www.oracle.com/

からダウンロードします。

しかし、SunOracleに買収されたのは未だにショックです。。

というのはおいといて

ダウンロードしてきたJDKを解凍し、/usr/localに移動します。

JAVA_HOMEを設定します。

/etc/environment

を追加

その下にあるPATHにも

を先頭あたりに追加

続いてScalaのインストール

http://www.scala-lang.org/

からダウンロード

解凍

scala/usr/localに移動します。

JAVA_HOMEと同様にSCALA_HOMEを設定します。

/etc/environment

を開いて、JAVA_HOMEの下に

を追加

その下のPATHにも

を追加。

最終的に、PATHは以下のようになると思います。

次にImageMagickのインストール

jMagickaptでインストール

若干パッケージ名が違うので注意

パッケージで入れた場合、jmagick6.jar/usr/share/javaに置かれます。

libJMagick.soですが、

/usr/lib/jniに入ります。

このjni、パスが通っていませんので、後々エラーが出ると思うので

ここでパスを通しちゃいます。

/etc/bash.bashrcあたりに

を追加しておきます。

次にPlay Frameworkを入れます。

http://www.playframework.org/

からダウンロード

今回は2.0を使っています。

1.x.xではないです。

ダウンロードした物を解凍

play自体は、個人用ホームに置きます。

playコマンドにエイリアスを設定

~/.bashrc

を追加

これで、playコマンドがたたけるようになりました。

早速新しいプロジェクトを作成します。

ImageResizerディレクトリに入ります。

libディレクトリを作成します。

とりあえず、/usr/share/javaからjmagick6.jarをこのlibにコピーします。

ちょっとめんどくさくなってきたので、ソースを貼り付けます。

#/app/controller/ImagesController.scala

#/conf/routes

 

テスト用の画像をどこからか持ってきます。

/images/sample

に入れます。

このsampleというディレクトリは

イメージタイプとしてURLから指定可能なように作ってみました。

このプロジェクトを実行します。

URLにアクセスしてみます。

http://localhost:9000/images/sample/Chrysanthemum/200×200/b0f87c3f6aa9818bfa2942a6224a9648.jpg

どうでしょうか、縮小されたイメージが表示されましたでしょうか。

このImageResizerの今後の展開ですが

まだ未実装な部分を実装していきます。

また、

/imagesに置いた画像から、別の拡張子の画像を生成できるように

というのも実装したいと思います。

[Scala]Play! Framework2で、Ruby on Railsのmigrationのような事

Ruby on Railsは、フルスタックで、テーブルのスキーマもリビジョン管理が出来るフレームワークですが、Play! Frameworkもそれに近い事が可能となっています。

Ruby on Railsで言うマイグレーションファイルは、Play! Frameworkでは

conf/evolutionsディレクトリになります。

このディレクトリに1.sqlという感じに、連番でsqlファイルを作成すると
その順番で実行時にスキーマの更新が行われます。

では、この1.sqlのファイルの中身はというと

という感じになります。

この中でキーになるのが

!Ups

!Downs

です。

!Upsの下に書いたSQLが、1.sqlのスキーマ更新処理

!Downsの下に書いたSQLが、1.sqlの更新を取り消す時の処理になります。

!Downsに書いた処理を実行する方法ですが

これは調査中です。。

Play! Framework 2に、なぜか、evolutionsコマンドが無くなっているので…。。

[Scala]Play frameworkで作ったプロジェクトをeclipseで編集する

Play frameworkでは、eclipseでプロジェクトを開けるようにするコマンドが存在するのでその機能を使用する。

まず、作ったプロジェクトのディレクトリに移動する。

コマンドを叩く

これで、eclipseで読み込む準備が完了

続いてeclipse側でPlayScalaExampleをインポートします。

eclipseのworkspaceにPlayScalaExampleを移動して、eclipseのメニューから
[File]-[Import…]-[Existing Projects info Worksplace]を選択
PlayScalaExampleを選択して完了するとインポート完了。

[Scala]Play frameworkでHello Worldちょい手前まで

Liftを使うかPlay frameworkを使うか、というところで、悩んでいるので

とりあえず、Play frameworkも試してみる。

Scalaをセットアップするのは、JDK入れて適当な場所にScalaを展開してパスを通すだけで良いので、これは省略する。

Play framework

本家(http://www.playframework.org/)

からダウンロードする。

Scalaを展開したディレクトリの隣あたりにPlay frameworkを展開。

Play frameworkへのパスを通す

コマンドラインで

と入力すると、play frameworkの実行メッセージが表示されれば正常に設置が完了している。

Play framework 2.0だと、ここまでやるだけで、なんかScalaモジュールが入るっぽいのですが

入っていない場合は

を実行する。

続いて、プロジェクトを作成する。

プロジェクトをおきたいディレクトリまで移動して

を実行。

と聞かれるので、そのままリターン

と聞かれるので、Scalaを使うので「1」を入力してリターン

以上で、プロジェクトの作成が完了。

Ruby on Railsっぽく、ここまま起動すると初期画面が出ると思うので、
とりあえずプロジェクトを実行してみる。

まずは、作成されたプロジェクトのディレクトリに移動。

続いて、実行

これで、localhostの9000番でプロジェクトが起動される。

続きはまた後ほど