akka (12 posts)

とりあえず使えるようにする Akka-Persistence で Kryo をとりあえず使えるようにする設定については以前書いた。 [Akka-Persistence コトハジメserializer として kryo を使う](http://qiita.com/petitviolet/items/92826357bd10aace14f5serializer%E3%81%A8%E3%81%97%E3%81%A6kryo%E3%82%92%E4%BD%BF%E3%81%86) serializer 選択について Akka-Persistence のPersistentActo

実装してみる理由 ReactiveSystem や Microservices 等の文脈で登場する CircuitBreaker について以前調べた。 - [[Akka]CircuitBreaker はどう動くのか - Qiita](http://qiita.com/petitviolet/items/777be810e3c5756a393d) - [Akka の CircuitBreaker と Netflix の Hystrix の違い - Qiita](http://qiita.com/petitviolet/items/f1975fba06655a95e3b0) Circu

この記事はなに？ マイクロサービス等の文脈で登場する[CircuitBreaker](http://martinfowler.com/bliki/CircuitBreaker.html)。 Scala で使えるものの代表(要出典)として以下の 2 つを比較する。 - [Circuit Breaker - Akka Documentation](http://doc.akka.io/docs/akka/current/common/circuitbreaker.html) - シンプルだが単機能 - [Netflix/Hystrix](https://github.com/Netf

CircuitBreaker とは 原典にあたるのは[Martin Fowler 氏の post](http://martinfowler.com/bliki/CircuitBreaker.html)になるはず。 リモートへのリクエストが失敗した時にうまいこと障害が伝搬しないようにするためのデザイン。 昨今の Microservice アーキテクチャな文脈だと考えやすい。 特定のサービスがダウンしてしまった時に、 それに依存するサービスが引きずられてダウンしてしまわないようにするもの。 Reactive なシステムを作る上で欠かせない存在になりそう。 CircuitBreak

[Akka-Stream](http://doc.akka.io/docs/akka/current/scala/stream/)でアプリケーションを実装する場合、 Source と Flow と Sink を組み合わせてRunnableGraphを構築し、runして実行する。 本記事では Akka-Stream の部品のメインとなる Source, Flow, Sink を、 [Akka-Actor](http://doc.akka.io/docs/akka/current/scala/actors.html)および[ActorPublisher](https://github.

状態の保持/状態遷移に長けた[FSM](http://doc.akka.io/docs/akka/current/scala/fsm.html)と、その状態/状態遷移を永続化する[Akka-Persistent](http://doc.akka.io/docs/akka/current/scala/persistence.html)の組み合わせとして[PersistentFSM](http://doc.akka.io/docs/akka/current/scala/persistence.htmlPersistent_FSM)がある。 状態を持つ Actor でイベントを永続化したいケー

[Akka-Persistence](http://doc.akka.io/docs/akka/current/scala/persistence.html)は stateful な actor の内部状態を永続化することによって、生成時、再開時、migration 時などに状態を復旧することを可能とするもの。 内部状態に至るまでのイベント(メッセージ)を永続化しておくことで、そのイベントを再生すれば全く同じ状態を再現させることが出来るため、CQRS/ES の文脈で最近はよく出てきている(気がする)。 build.sbt まずは build.sbt に依存を追加する。 バージョンは

有限オートマトン？ Finite State Machine(FSM) ざっくり言うとイベントを受け取って状態遷移するステートマシン。 詳しくは[Wikipedia](https://ja.wikipedia.org/wiki/有限オートマトン)参照 FSM を Actor で実装する まさにそのためのakka.actor.FSMがあるので、これを使って実装する。 FSM に必要な型を定義する 必要となるのは以下の 3 つの型 - State - FSM の状態 - Data - FSM が内部的に持つ情報 - Event - FSM の

akka.http.scaladslパッケージを import することで使えるようになる DSL が、 裏側でどのように実装されているか気になったので調べた。 題材 akka-http において、単純なルーティングについて考えてみる。 scala val route = path("ping") { get { complete("pong") } } localhost:8080/pingに GET リクエストを送ると期待通りにpongと返ってくる。 $ curl localhost:8080/ping pong

http リクエスト/レスポンスでやり取りする String な値をアプリケーションが期待する Scala の型に変換する方法について。 リクエストを型で縛る ユーザーからのリクエストをなるべくStringとして触らないようにする。 URL パラメータ 以下のルーティングを考える。 GET /message?id=&body=' URL パラメータのidとbodyをなるべくString以外で扱う。 まず、型を用意する。 scala sealed trait Content { val id: Long

標準で用意されていない独自のヘッダーを定義して使いたいケース。 大雑把に、文字列として扱う場合と型で扱う場合に分ける 文字列で扱う headerValueByNameで良い。 引数にSymbolかStringを渡せば、それにマッチするヘッダーの値が取り出せる。 scala val route = path("header" / "ping") { get { headerValueByName('Message) { msg: String => complete(s"pong: $msg") } }

Path を構築するための DSL であるDirectiveとPathMathcerについて。 ドキュメントは以下。 [The PathMatcher DSL — Akka Documentation](http://doc.akka.io/docs/akka/2.4.4/scala/http/routing-dsl/path-matchers.html) tl;dr 大体ここに書いてある。 [The PathMatcher DSL — Akka Documentation](http://doc.akka.io/docs/akka/2.4.4/scala/http/rout