問題タブ [orleans]

GrainA と GrainB という 2 つの Grain があります。GrainB は GrainA に依存します。Orleans のサンプルを見て、TestGrainFactoryテストできるローカル グレインを作成できます。Grain が単純な場合、簡単にテストできます。しかし、私の問題では、GrainB は GrainA に依存しています。どうすればテストを完了できますか?

StatelessWorkers の使用に関する詳細なドキュメントを見つけるのは難しいと思います。

これに似た何かを達成したい。ドキュメントで提案されているように、いくつかのメッセージを処理し、最終的に状態を保持するグレインをアクティブにするために、ステートレス ワーカーを使用する必要があります。

このグレインは決して状態を処理せず、メッセージを順番にキューに入れる必要がないため、「初期化」を処理するディスパッチャーグレインの複数のインスタンスが必要です。

このグレインをリエントラントとしてマークする必要がありますか? または StatelessWorker (属性) で十分ですか?

アクティベーションに関しては、IGrainWithIntegerKey（または同様のインターフェース）から継承する必要があるようです。これは、次のようにグレインを有効にする必要があることを意味します。

ID として常に 0 を使用しているため、グレインの複数のインスタンスがアクティブ化されますか? または、別の ID を作成する必要がありますか。次のように穀物を呼び出すことができないようです：

たとえ継承したとしてもIGrain

プッシュ通知サービス (SignalR/WebAPI 経由で行った) と、特定の日時または定期的な間隔で実行できる将来のタスク ランナー/スケジューラーを作成する必要があります。

ユース ケースの例としては、支払いリマインダー サービスがあります。支払いが期日までに支払われない場合、システムは「管理者」に通知を送信し、「消費者」に電子メール/SMS を送信します。リマインダーは、手動または自動で、別の日付にスヌーズしたり、新しい日付変更線に更新したりできます。

スケジューラ サービスは、手動の Todo の設定、定期的なリマインダー、将来の電子メール/SMS 送信日など、他の用途にも使用できる可能性があります。また、日時ごとに潜在的に数千のニュースレターの電子メールを見ています。

私はいくつかのオプションを調べました

1) Quartz.net / Hangfire / バックグラウンド タスク

--> asp.net または Windows サービスとして実行できます。

--> スケジュールされたタスク/定期的なサポートなどがあります...

--> 私には非常に複雑に思えます。また、スケーラブルではない asp.net サービスと組み合わせると、おそらく効率的ではなく、将来の校正のために適切に設計する必要があります...追加のストアをセットアップする必要がありますか?

2) タスクスケジューラ

--> 私の焦土/不死鳥の展開シナリオではあまり実現可能ではありません

3) 外部サービス

--> Azure スケジューラ

--> AWS Cloudwatch スケジューラ / イベント (SNS / Lambda などもトリガーできます...)

--> 非常に優れた分離ソリューションのようですが、メンテナンス/テスト/耐久性が問題になる可能性がありますか? ソリューションに応じて適切にセットアップする必要があります...「12 Factor's App」の製品/開発パリティテストなどを取得する方法がわからない...

4) イベント駆動メッセージバス

--> バスは耐久性や信頼性に優れていますが、キャンセルしたい場合などは複雑になります..?

--> 今後のスケジュールの制限、SQS は 15 日間の制限しかないと思います。

5) アクターモデル

--> Akka.net または Orleans、セットアップは簡単に思えますが、まだ使用していませんが、特定のタスクを実行する小さなアクター、スケジューラー、高性能、クラスターの追加が容易な、目的に合ったものがたくさんあるようですより多くのジョブ (すべてのロジックはアクターごと、残りは構成) の場合、ローカルで簡単に再現でき、優れています...単一の作業単位アクターは私にとって非常に理にかなっています。

--> 経験はありませんが、私のシナリオではやり過ぎでしょうか? 本格的なスケジューラーにとっては、将来的にも良いことのように思えます。

--> 否定。dotnet コアのサポートはまだありません

その他の提案は歓迎します...2 週間以内に完了する必要があります。

PS Google Now Reminders のアーキテクチャとは何なのか本当に疑問に思っています。

ASP MVC クライアントで MS Orleans を使用したいと考えています。このコンステレーションで mvc アプリを Orleans Client Observer として使用したいと考えています。threadlifetime / apppool のリサイクルなどで問題が発生する可能性はありますか? オルレアンの文書によると

クライアント部分、通常は Web フロントエンド...

...たとえば、Web サーバーで実行されている ASP.NET アプリケーションは、Orleans アプリケーションのクライアント部分になることができます。クライアント部分は .NET スレッド プール上で実行され、Orleans ランタイムのスケジューリングの制限と保証の対象にはなりません。

しかし、これをどのように解釈するかはよくわかりません。

1.3.0 にアップグレードしたばかりで、一般的な穀物に問題があります。

この問題を示すインターフェイスとクラスの例:

次に、次のように使用します。

グレインの取得は問題ないようですが、グレインでメソッドを呼び出すと、次のようになります。

足りないものはありますか？多分新しい構成？これは、私が使用していた以前のバージョンで問題なく動作しました。

編集：

インボークインターセプターの問題のようです：

providerRuntime.SetInvokeInterceptor((メソッド、リクエスト、グレイン、インボーカー) => { インボーカーを返す.Invoke(グレイン、リクエスト); });

それが削除されると、すべてが機能します。

テスト Orleans アプリケーションのメンバーシップ プロバイダーとして、既存の Consul クラスターを使用しようとしています。

クライアント アプリを Silo に接続すると、このエラーが発生します

Orleans.Runtime.Host.ConsulBasedMembershipTable にゲートウェイが見つかりませんでした。Orleans クライアントを初期化できません。

ConsulUtils クラスを掘り下げると、取得されるエントリには ProxyPort が定義されておらず、破棄されるため、空の結果セットになります。

次のようにサイロを初期化します。

そして、クライアント アプリを次のように設定します。

ConsulUtils のコードを見ると、エントリの保存時に ProxyPort が設定されていない (つまり 0 である) ことがわかります。したがって、サイロを初期化するときに問題があると想定していますが、それが何であるかわかりません!

Orleans サイロに最適な最小または推奨ハードウェア (主にコア RAM) は何ですか? CPU タスクと IO タスクを持つアプリケーションの場合、orleans はどの基準でスケーリングを決定し、クラウドにノードを追加しますか?