問題タブ [play2-mini]

Play2-miniをScalaで使用して、モバイルクライアントと既存のWebサービスの間に位置するサービスを開発する可能性を評価しています。Play2-miniがサーバーとクライアントを実装するコードの最も単純な例を探しています。理想的には、クライアントはAkka2アクターを使用します。

この質問では、それがどのように行われるかを調べようとしていますが、Play2-MiniとAkka2がどのように連携する必要があるかについても調べています。Play2-MiniはAkkaHTTPモジュールの代わりになるようです。

Play2-miniには、次のコード例が含まれています。このコード例では、2つのTODOを作成しました。誰かが開始するためのサンプルコードを手伝ってくれるなら、私は本当に感謝します。

Akka 2 のリリースにより、Akka HTTP モジュールはPlay2-miniを使用するオプションに置き換えられました。ここで、Play2-mini は Play2 からモデル ビュー コントローラーを除いたものに見えます。

REST サービスの実装と HTTP クライアントの作成の間の線はグレー表示されています。たとえば、Web サービス (REST である必要はありません) と HTTP クライアントを 1 つのサービス (つまり、HTTP プロキシ) で作成したいとします。Akka と Play2-mini のどちらを使用しますか?

Finagle でこのようなサービスを作成しましたが、Akka や Play2-mini を使用してこの演習をやり直して、比較する方法を確認したいと思います。

大まかに言うと、アーキテクチャはどのようなものですか? これらの製品はどのように組み合わされますか?

play-miniアプリケーションから画像を提供しようとしています。

残念ながら、これは機能しません:)次のエラーが発生します

Akka は夢が叶ったようです。悲しいことに、他の多くのソフトウェアと同様に、ドキュメントとサンプルがいくつかの主要な点で欠けています。肝心なのは非ブロッキングの並列 io を提供することなので、なぜ文字列を返すだけの hello world を提供するのでしょうか。ここに面白いアイデアがあります: 各単語のエージェントを用意し、Web 上で何かを呼び出して別の言語に翻訳し、結果を返します。

私は今日、Futures と Promises に関するドキュメントを読みながらぐるぐる回りました。実用的な例が 1 つあれば、すべてが不要になります。

私は、Java 同時実行パッケージで Future を使用して多くの並行プログラミングを行ってきました。どういうわけか、Akka は複雑すぎるように思えます。私は、上で説明したことに非常に近いことを行っています: リクエストを取得し、複数のエージェントに Web 経由で対応させます。マスターとリスナーを出発点とする元の生成プロジェクトを使用しましたが、正常に動作します。集約された結果を返す簡単な方法がわかりません。呼び出される play-mini メソッドがあります。そこから、メッセージをエージェントに送信するクラスのメソッドを呼び出しています。エージェントの実行が完了すると、結果が集約され、Listener が呼び出されます。そこから Future を構成するにはどうすればよいですか? すべてのドキュメントにはブロックしないと記載されていますが、REST 要求から戻る必要があります。

そのような例を知っている人はいますか？超シンプル。ありがとう。

私は Akka と Play Mini を使用しています (これは Netty の上にある単なる REST レイヤーです)。私はJavaからそれを使用しています。構文は単純で、GitHub の readme で説明されています。

これは正常に機能していますが、すべての URL が長いパスのみである必要があることを意味します。パラメータが禁止されていると主張する人もいれば、絶対に禁止されていないと主張する人がいるこのスレッドを見つけました。プレイドキュメントが自分の立場を述べただけでいいのにと思いますが、残念です。次の形式の URL をサポートする機能を探しています。

たぶん、通常の Play ドキュメントがこれに対処しています。探し続けます..

Play-miniでデプロイされたAkka2を使用してアプリで作業しています。ログバックをプロジェクトにプルバックすると機能しますが、その構成が踏みにじられるため、Joran構成メソッドを実行し、起動時に呼び出す必要がありました。次に、Playがログバックに移行したことを読んだので、Playに組み込まれているロガーの使用方法を調べて、それを理解しましたが、入力するとすぐに次のようになります。

サポートするのは次のとおりです。

ログバックの要点は可変引数のものであるため、コードを次のように汚す必要はありません。

だから私は何かが欠けているに違いない。この分野でもドキュメントは優れていません。

ところで、これは設定が混乱することについてのスレッドです。

したがって、基本的に、conf ファイルの JSON 定義からクラスのインスタンスを作成できるようにしたいと考えています。ドキュメントを調べたところ、JSON 構造で定義されているものを参照する方法があることがわかりましたが、そのような定義からオブジェクトをインスタンス化する最善の方法について疑問に思っていました。たとえば、4 つまたは 5 つのプロパティを持つ RemoteRepository というクラスがあるとします。JSON ファイルに一連のエントリを作成し、起動時に読み込み、RemoteRepository オブジェクトのコレクションを取得したいと考えています。もちろん、グラフを含むデータベースでこれを行うこともできますが、可能であればJSONだけを行いたいと考えています。

大規模な Scala + Akka + PlayMini アプリケーションを外部 REST API と接続しようとしています。ルート URL を定期的に (基本的には 1 ～ 10 分ごとに) ポーリングし、サブレベルの URL をクロールしてデータを抽出し、メッセージ キューに送信するという考え方です。

これを行うには、次の 2 つの方法を考え出しました。

第1の方法

API のリソース パス構造に一致するアクターの階層を作成します。Google Latitude の場合、たとえば次のようになります。

• アクター「latitude/v1/currentLocation」ポーリングhttps://www.googleapis.com/latitude/v1/currentLocation
• アクター「latitude/v1/location」ポーリングhttps://www.googleapis.com/latitude/v1/location
• アクター「latitude/v1/location/1」の投票https://www.googleapis.com/latitude/v1/location/1
• アクター「latitude/v1/location/2」の投票https://www.googleapis.com/latitude/v1/location/2
• アクター「latitude/v1/location/3」の投票https://www.googleapis.com/latitude/v1/location/3
• 等

この場合、各アクターは、関連するリソースを定期的にポーリングし、次のレベルのパス リソースの子アクターを作成/削除します (つまり、アクター 'latitude/v1/location' は、アクター 1、2、3 などを作成します)。https://www.googleapis.com/latitude/v1/locationのポーリングを通じて学習したすべての場所)。

2番目の方法

ルーターによって負荷分散されたポーリング要求 (リソース パスを含む) を受信する同一のポーリング アクターのプールを作成し、URL を 1 回ポーリングし、何らかの処理を行い、ポーリング要求をスケジュールします (次のレベルのリソースとポーリングされた URL の両方に対して)。 . Google Latitude では、たとえば次のようになります。

1 ルーター、n ポーラー アクター。https://www.googleapis.com/latitude/v1/locationに対する最初のポーリング リクエストは、 https://www.googleapis.com/latitude/v1/location/1、https:/に対するいくつかの新しい (即時の) ポーリング リクエストにつながります。 /www.googleapis.com/latitude/v1/location/2など、および同じリソースに対する 1 つの (遅延した) ポーリング リクエスト、つまりhttps://www.googleapis.com/latitude/v1/location。

私は両方のソリューションを実装しましたが、少なくとも私が興味を持っている API とポーリング頻度については、関連するパフォーマンスの違いをすぐに観察することはできません。 .scheduler.schedule(...) 2 番目のアプローチ (ここでは、scheduleOnce(...) が必要) よりも。また、リソースが複数のレベルでネストされており、存続期間がやや短い (たとえば、各ポーリング間で複数のリソースが追加/削除される可能性がある) と仮定すると、akka のライフサイクル管理により、最初のケースでブランチ全体を簡単に強制終了できます。2 番目のアプローチは (理論的には) 高速であり、コードの記述もやや簡単です。

私の質問は次のとおりです。

1. (パフォーマンス、拡張性、コードの複雑さなどの点で) どのアプローチが最善と思われますか?
2. どちらかのアプローチ (特に最初のもの) の設計に何か問題があると思いますか?
3. 誰かが似たようなものを実装しようとしましたか? それはどのように行われましたか？

ありがとう！

Play-mini と Akka (これ)に関する letitcrash.com のブログ投稿を読みましたが、Akka マイクロカーネル内で Play-mini を使用する方法については頭に浮かびません。Global オブジェクトを使用しないので、手動で play-mini をオンにする必要がありますよね? 問題は、それをどのように行うかです。