問題タブ [akka-persistence]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - Akka Persistence - Recovery の問題 - 診断方法は?
PersistentActor を拡張し、RecoveryCompleted と RecoveryFailure の両方を処理するアクターがいくつかある akka-persistence 2.3.4 の Java バージョンを使用しています。デフォルトのジャーナリングとスナップショットのプラグインを使用しています。
一部のアクターで RecoveryCompleted メッセージも RecoveryFailure メッセージも表示されず、アクターが動かなくなるという回復の問題が発生しています。
なぜこれが起こっているのかを理解するために、どのような種類の診断を使用できますか?
デバッグ ログを有効にしようとしましたが、akka ログが表示されません。
java - データのブートストラップ Play フレームワーク 2.3.3
アプリケーションが最初にビルドされるとき (「アクティベーター実行」を実行した後) に、いくつかのデータをプリロードしたいプレイ フレームワークのプロジェクトがあります。
/confフォルダーに「initial-data.yml」ファイルを作成し、次のようなBootstrap.javaファイルを作成することで達成されていたことを私が理解していることから:
ただし、それは機能しなくなりました。
Play フレームワーク 2.3.3 でプロジェクトにデータをプリロードするにはどうすればよいですか?
scala - akka 持続性かどうか
現在のアプリケーションは、大量のデータをインポートするユースケースに Akkaイベントストリームとそのパブリッシュ/サブスクライブを使用し、パブリッシュおよびイベントごとにデータを受信すると、サブスクライバーが存在します。この設計では、パブリッシャー/サブスクライバーのいずれかで問題が発生した場合、イベントが失われる危険性があります。
いくつかの理由から、ここで Akka の永続性を使用することが理にかなっているのかどうか疑問に思っています。
1) イベントの永続化 2) 監査履歴 3) スナップショットを使用したシナリオの再作成
システムには共有/グローバル状態 (ほとんどすべての Akka 永続化ブログ/例で一般的にユースケースとして説明されています) がないことに注意してください。
ここで Akka の永続性は理にかなっていますか?
akka-persistence - スナップショット プラグインとイベント ストアの最も軽いメモリおよび CPU の組み合わせは何でしょうか?
内部メトリック収集サーバー ソリューションの POC に Akka Persistence を使用しています。現時点では、(メモリと CPU に関して) 可能な限り軽くしたいと考えています。インメモリ ジャーナルとファイル スナップショットを使用しています。すべてが機能します。唯一の問題は、スナップショットの数です。最後のスナップショット以外はすべて削除していますが (もちろん永続化アクターごとに)、ファイルの数はまだ多すぎます (多くのアクターを作成しています)。
では、スナップショット プラグインとイベント ストアの最適な組み合わせで、軽量化を維持できる提案はありますか?
- H2/Derby + JDBC?
- --smallfiles を使用したローカル MongoDB?
- 何らかの方法で埋め込みMongoを使用しようとしています(これまでに見たのはテスト目的のみであり、十分に安定しているかどうかはわかりません)?
- 他のアイデア?
現時点では分散する予定はありません。パフォーマンス テストでは、ユース ケースに十分な数値が得られているため、同じマシンにとどまることが適切であり、十分なはずです。
rest - Akka + Persistence を使用したシンプルな REST API の設計
API から定期的に作成して送信する必要があるいくつかのオブジェクトを生成するための単純な REST API を構築しています。オブジェクトの性質も、REST インターフェースをサポートするフレームワーク (Spray、Play Framework など) も関係ありません。私の質問は、Akka を使用したこのシステムでスケーラブルなアクターの設計として適切なものは何でしょうか? サービスがクラッシュしたり、移行されたり、サービスを停止させる原因が何であれ、サービスが停止したとします。どのオブジェクトをいつ送信する必要があるかについてのタスクの説明を回復するために、akka-persistence はここに行く良い方法ですか? それとも、従来の DB でそのようなものを永続化する方がよいでしょうか?
ありがとう。
注:また、自分自身はステートフルではないが、多くの子アクターを作成するアクターがいると仮定して、このアクターが再び子を作成するメッセージを再生するために akka-persistence を使用することをお勧めします。 (子も非ステートフルです)。
java - Play Framework による akka-persistence
私はPlay Frameworkプロジェクトをセットアップしました。それと共にakka-persistenceを使用したいと考えています。akka-persistence 用の JAR をダウンロードし、Play プロジェクトの lib フォルダーにドロップしました。akka-persistence クラスが認識され、アプリケーションをコンパイルして実行できますが、アプリケーションが起動するとすぐにNoClassDefFoundError
例外がスローされ、アプリケーションが停止します。以前に akka-persistence を使用したことがあります (ただし、Play Framework プロジェクトでは使用しませんでした)。ヒントはありますか?
注: 私は Play Framework 2.3.4 を使用しています (これは、akka-persistence モジュールを手動で削除した Akka 2.3.4 を使用していると思われます)。私は全面的に Java を使用しています (Scala ではありません)。akka-persistence の jar は akka-persistence-experimental_2.11-2.3.4.jar です。スローされた例外とスタック トレースは次のとおりです。
私のbuild.sbt:
scala - すべてのイベントが永続化された後にのみアクターの状態を更新する
持続アクターの receive メソッドで、持続したいイベントを大量に受け取り、すべてのイベントが持続された後でのみ、状態を再度更新します。どうやってやるの?
persist() 呼び出しはブロックされていないため、その直後にコードを配置できないことに注意してください。
更新: なぜこれが必要なのか
これらの新しいイベントは、外部 Web サービスから取得されます。私の永続的なアクターは、最後のイベント ID をその状態に保存する必要があります。これは、コマンドを受信したときに後続の ws 呼び出しに使用されます。問題は、これらのコマンドが同時に来る可能性があることです。そのため、ある種のロック システムが必要です。
- 受信した ws call コマンド: このコマンドが終了するまで、次のコマンドを隠しておきます (つまり、ブール値)
- ws から受信した応答: それらを保存し、状態を更新して最後の ID を保存し、隠し場所にあるすべてのコマンドに対して別の単一の ws 呼び出しを実行します (コマンドの送信者がそれらすべてに一度応答できるようにしています)それ以外の場合は、コマンドをもう隠しません。