問題タブ [orleans]

Azure にデプロイしようとすると、以下のエラーが発生します。私は基本的なハローワールドアプリをやっています。誰かが洞察を教えてください。以下にログを添付しました。

私は::バージョン1.1.0-beta2を使用しています

サイロはログ ファイルに従って適切に起動しますが、Azure でクライアントを初期化できません。クライアントで以下の構成ファイルを使用しています。

PS:: フュージョン ログを有効にした後でわかりました。1 つの dll が正しく読み込まれていないことがわかりました。問題は修正されました。

ライブネスのために SQL Server を使用する Orleans のテスト環境をセットアップしようとしています。これは私のサーバー構成ファイルです：

この構成を使用すると、実行時に次のエラーが発生します。

MembershipTableGrain は Seed ノードなしでは実行できません。サイロ構成ファイルをチェックして、SeedNode 要素が指定されていることを確認してください。または、LivenessType に AzureTable を使用することもできます。パラメータ名: グレイン = MembershipTableGrain 例外 = System.ArgumentException: MembershipTableGrain はシード ノードなしでは実行できません - サイロ構成ファイルを確認し、SeedNode 要素が指定されていることを確認してください。または、LivenessType に AzureTable を使用することもできます。

さらに上のログでは、Liveness が MembershipTableGrain (デフォルトであり、SeeNode が必要) であることが示されています。ここで何が欠けていますか？

オーリンズ向けの Azure Web サンプルを実行しています。ローカル開発サーバーで問題なく動作します。ただし、Azure にデプロイすると、サイロから応答が返ってきません。

デプロイは成功です。Web ロールが起動しますが、「ask orleans for details」をクリックすると、「talking to orleans...」と表示されますが、約 30 秒後に消えます。「返事が来ることを願っています...」というあざけりのメッセージが残っています。

構成はまったくありません。サンプル プロジェクトとオンライン チュートリアルの手順を使用しました。彼らが指示したとおりに公開され、その後は何も公開されませんでした。

Web ロールをデバッグすると、AzureClient で不明なエラーが発生しているようです。

エラー: 0 : Client.Initialize が exc で失敗しました -- 1 つ以上のエラーが発生しました..再試行します

情報: 0 : 一時停止 00:00:05 サイロとゲートウェイの登録を待機中 Deployment=70c88c32f1114e168826d757f982a210

Web ロールとワーカー ロールが異なるサブネット上にあることに気付きました。サーバー間の通信を妨げているファイアウォールがあるかどうかを調べます。

壊れる可能性のあるものについて何か提案はありますか? またはトラブルシューティング方法は？

次の問題があります。Orleans Grain の単体テストを実装しようとしていますが、開始時に dataprovider Default が見つかりません。例外はコンストラクター呼び出しで発生します。コードは次のとおりです。単体テストクラス

ここに私の設定ファイル OrleansConfiguration.xml があります

私が持っているエラーはこれです：

Exc レベル 0: Orleans.Runtime.OrleansException: 型 NBOOC.Grains.StorageProviders.CustomSqlStorageProvider,NBOOC.Grains 名のプロバイダー デフォルトが読み込まれませんでした。プロバイダー クラスが定義されているアセンブリを実行フォルダーにデプロイしたことを確認してください。

Orleans.Providers.ProviderLoader`1.ValidateProviders() で

Orleans.Providers.ProviderLoader 1.LoadProviders(IDictionary2 構成、IProviderManager providerManager で)

Orleans.Runtime.Storage.StorageProviderManager.LoadStorageProviders (IDictionary`2 構成) で

Orleans.Runtime.Scheduler.SchedulerExtensions.<>c__DisplayClassa.<b__8>d__c.MoveNext() で

ご覧のとおり、完全に指定されたタイプの Default という名前のプロバイダーがあります。そこに指定されたクラスは、すべての参照が存在するためアクセス可能です。これを明示的に確認しました。すべての DLL は、単体テスト DLL と同じフォルダーに配置されています。また、Orleans DLL のすべてのバージョンを確認しました。これらはすべて同じ 1.0.10.0 であるため、バージョンの問題ではありません。誰もそのようなことに直面したことがありますか？それを修正する方法はありますか？

PS ところで、参考になる場合に備えて。Orleans のソースをダウンロードし、例外が発生する場所を追跡しました。ProviderLoader クラスがあり、プロバイダーのディクショナリがありますが、何らかの理由で空です。

プロジェクトのためにオルレアンに慣れ始めたところです。それに関していくつか質問があります。現在、ステップ バイ ステップ チュートリアルを使用しています。残念ながら、ラップトップで「Running in a Stand-Alone Silo」を使用して例を実行しようとすると、多くの例外が発生して Grains コレクションが失敗します。それをトラブルシューティングする方法がわかりませんか？

ドキュメントには、「OrleansHost.exe は、Windows Server で Orleans コードを実行することを目的とした既製のホスト実行可能ファイルです (Azure には別のホストがあります)」と記載されています。これが何を意味するのかわかりませんか？これが、Windows 10 を実行しているラップトップで動作しない理由ですか?

スプリットブレインが発生する可能性がある場合に Orleans FAQ を読みましたが、どのような問題が発生する可能性があり、それを適切に処理する方法がわかりません。

FAQ は次のような漠然としたものを言います:

アプリケーションを作成する際に、アクターのインスタンスが 2 つあるというまれな可能性を考慮する必要があります。

しかし、実際にこれをどのように考慮すればよいのでしょうか? そうしないとどうなるでしょうか?

Orleans Paper ( http://research.microsoft.com/pubs/210931/Orleans-MSR-TR-2014-41.pdf ) は次のように述べています。

アプリケーションは、外部の永続ストレージに依存して、より強力なデータの一貫性を提供できます

しかし、これが何を意味するのかわかりません。

スプリットブレインが発生したとします。これで、1 つのグレインのインスタンスが 2 つになりました。いくつかのメッセージを送信すると、それらはこれら 2 つの (またはさらに多くの可能性があります?) 異なるインスタンスによって受信される可能性があります。これらのメッセージを受信する前の各インスタンスが同じ状態であったとします。これらのメッセージを処理した後、状態が異なります。

どのように状態を維持する必要がありますか? 競合が発生する可能性があります。

別のインスタンスが破壊され、1 つだけが残る場合、破壊されたインスタンスの状態はどうなりますか? それらによって処理されたメッセージが処理されたことがないようなものでしょうか? 次に、クライアントの状態とサーバーの状態が非同期化された IIUC になる可能性があります。

これ（スプリットブレイン）は大きな問題だと思いますが、なぜそれほど注意が払われていないのか理解できません。

Orleans で、同じタイプの X 個のリマインダー グレインが異なるサイロでホストされていることを確認する方法はありますか?

動機: バックグラウンド処理を実行する Azure クラウド サービスで Orleans を使用したいと考えており、インプレース アップグレードによる障害やサイロのダウンタイムに対して高い回復力を備えている必要があります。私のシナリオでは、タイマーを使用して常にアクティブなグレインが必要です。サイロをホストしている場合は、数秒で別のサイロで再度アクティブ化する必要があります。Azure クラウド サービスのアップグレード中、インスタンスは 5 つのグループに分割され、一度に 1 つのグループがアップグレードされます。つまり、アップグレード中は常にインスタンスの 20% がシャットダウンされているため、常にアクティブなグレインを維持することは困難です。私は Sergey Bykov に相談し、いくつかのアイデアを思いつきました。そのうちの 1 つは、「常にアクティブな」グレインに ping を実行してアクティブであることを確認する「キープ アライブ」グレインを導入することでした。