問題タブ [azure-service-fabric]

ビルド サーバーで Service Fabric アプリケーションをビルドしようとしています。.sln ファイルをビルドすると、sfproj の Package ターゲットが実行されません。予想通り。MSBuild でこのターゲットを実行できないようです。

まず、.sln ファイルに対してビルドするときに使用できるターゲットは、標準のビルドおよびパブリッシュ ターゲットのみです。

次に、.sfproj 自体に対してビルドすると、ターゲットが実行されます。ただし、$(BuildPlatform) の不一致のため、.sfproj によって参照されるプロジェクトは正しくビルドされません。.sfproj には x64 プラットフォームがあります。私の他のプロジェクトのほとんどは Any CPU です。

これは Service Fabric に関する質問ではなく、一般的な MSBuild に関する質問だと思います。プロジェクトのすべてのプラットフォーム オプションを統合する必要のないソリューションを探しています。Service Fabric は本当に x64 のみであり、私の他のプロジェクトは本当にすべての CPU です。

[編集]

私はこれを解決しました。私がしたことは、.sfproj ファイルに という新しいターゲットを追加し、MaybePublishそれをデフォルトのターゲットの 1 つとして設定することでした。for がMaybePublishあります。に設定しています。基本的に、ソリューションのビルド時にプロパティが設定されている場合、このターゲットはオプションで Service Fabric アプリケーションをパッケージ化します。Condition'$(Package)' == 'true'DependsOnTargetPackage

これはおそらくDeployOnBuild、Web パブリッシング プロジェクトで機能する方法だと思います。Service Fabric ターゲット ファイルには、既定でこの種類のサポートが含まれている必要があります。

アクターが送信された順序でメッセージを処理する必要があるという問題があります。Akka では、アクター A とアクター B の間のメッセージは常に、送信された順序で到着することが保証されています。これは、Service Fabric の Reliable Actors には当てはまらないようです。私のテスト ケースでは、メッセージは非決定的な順序で受信されます。

最初のメッセージが処理されるまで次のメッセージを送信しないことで順序付けを強制できますが、これではポイント全体が無効になります。私は本当にメッセージを送信して忘れたいのですが、受信側のアクターによって順番に処理されることを知っています。

これを行うためのパターンを見た人はいますか？Orleans Actors にも、同様にメッセージの順序が乱れる可能性があると思います。おそらく、Orleans ソリューションもここで機能するでしょう。

サービス ファブリック アプリケーションには、 を介して HTTP エンドポイントを公開するステートレス サービスが含まれていますOwinCommunicationListener。

このサービスの ServiceManifest.Xml は、サービス エンドポイントを指定します<Endpoint Name="ServiceEndpoint" Type="Input" Protocol="http" Port="8090" />

ステートレス サービスは、 http://localhost:8090/のブラウザーを介してアクセスできます。

私たちがやろうとしているのは、ApplicationManifest を使用して、同じ Service Fabric アプリケーション内の異なるエンドポイントでこのサービスの複数のインスタンスをインスタンス化することです。

はServiceManifestImportサービス パッケージをインポートし、アプリケーション レベルでの構成のオーバーライドを可能にします。この方法で ServiceEndpoint をオーバーライドすることはできません。Settings.xml の値のみです。

Service下に複数のノードを指定することで、サービスの名前付きインスタンスを作成できますDefaultServices

構成を通じて、サービスのインスタンスごとに構成のオーバーライドを指定することはできますか?

I tried to make the service instances listen on a specific port by using their service name to work out which port so FooInstanceA listens on port 8090 and FooInstanceB listens on 8091.

Clearly Service Fabric is doing some magic during deployment because when FooInstanceB listens on a port other than the one specified on the ServiceEndpoint configuration the service is not accessible.

The first reason is the DACL is not set on the endpoint, this is resolved by running;

This allows the services to come up and show healthy in the Service Fabric Explorer, however the FooInstanceB is responding with an HTTP 503 error when we access with http://localhost:8091/

How can we get the service instances listening on different ports?

I hope that's clear, thank you.

メッセージインスペクターによって提供されるwcfのような認証、検証、またはリクエストの相関などの機能をフルフィルするためにペイロードをデシリアライズせずに、追加情報を運ぶためにカスタムメッセージヘッダーを送信リクエストに挿入することは可能でしょうか?

Reliable Collection (キュー) の値には、いくつかの複合型が格納されますSomeUnit。

私はそれをとしてマークし[DataContract]、それはメンバーであり、その上に属性も[DataMember]追加しました。[KnownType(typeof(SomeUnit))]

SomeUnit がシリアル化されたように見えますが、逆シリアル化例外がスローされます。

要素 'urn:ServiceFabric.Communication:item' には、名前 ' http://schemas.datacontract.org/2004/07/RP.Core:SomeUnit ' にマップされるタイプのデータが含まれています。デシリアライザーは、この名前にマップされる型を認識しません。DataContractSerializer を使用している場合は DataContractResolver の使用を検討するか、'SomeUnit' に対応する型を既知の型のリストに追加します。たとえば、KnownTypeAttribute 属性を使用するか、シリアライザーに渡される既知の型のリストに追加します。

どうすれば解決できますか？

サービス ファブリック ステートフル アクター サービスを試してみたかったので、VS2015.1 で適切なプロジェクトを作成し、生成されたコードを変更しませんでした。次に、ソリューションを実行/デバッグしました。次のエラーを受け取りました。

アプリケーション内の既存のサービス間に何らかの干渉がある可能性があると考えて、まったく新しいサービス ファブリック ソリューションとステートフルなアクター サービス プロジェクトも構築しました (すべての既定値を使用します)。このプロジェクトはまったく同じ方法で失敗しました。

1. 他の誰かがこの動作を確認できますか? （私の開発環境にあるものかもしれません）
2. 何が起こっているのかについて何か提案はありますか？
3. 何が失敗したかについてより多くの情報を得る最良の方法は何ですか? （そのコム境界を越えることはあまりないようです）
4. Visual Studio ツール以外でこれを試みる必要がありますか?

更新 1:

COMException を却下すると、次のようにもなります。

更新 2:

Visual Studio 2015.1 のインストール/アップグレードで問題が発生したため、それがこの問題と関係があるかどうかはわかりませんでした。さらに、同僚は同じ手順に従い、問題はありませんでした. そのため、VS2015.1、SF SDK、およびすべての前提条件を直接再インストールしました。残念ながら変化はありません。:(

また、このエラーが発生するたびに、Service Fabric Local Cluster Manager も壊れます。マネージャーを開こうとすると、「ローカル クラスター マネージャーを開けませんでした」という通知が表示されます。

また、実際にソリューションのスタートアップ プロジェクトとして SF アプリケーション プロジェクトを使用しています。(繰り返しますが、他の SF アプリケーションを動作させました... 新規または既存の SF アプリケーションでステートフルなアクター サービスを試すとすぐに停止します)。

更新 3:

これをもっと早く提供することを考えるべきでしたが、ここにコールスタックがあります...リマインダーと関係がありますか?

更新 4

私はより強力な (そして診断の少ない) アプローチを使用しました。開発マシンを再構築しました。Update 1 のインストールで発生した奇妙な動作に基づいて、ビルド ボックスが侵害されたのではないかと心配しました。OS を再構築し、vs2015.1 と SF SDK を再インストールしたところ、問題なく動作するようになりました。あなたの走行距離は異なる場合があります:|

ある種の長期的なコールバック戦略を維持できるサービスを開発するための最良のパターンを見つけようとしています。たとえば、 service があるとしますDoLongThingService。このサービスを呼び出すと.Begin、長いプロセスの実行がスケジュールされます。プロセスが終了したら、最初のサービスを起動する必要があります。基本的には長期ワークフロー系のもの。

これは、実際には俳優とうまく機能します。ActorReferenceメソッドにを渡すことができるのでDoLongThingService.Begin、そのサービスはBindそのアクターにメソッドを呼び出して完了を知らせることができます。

しかし、Actors を使用していない場合はどうでしょうか? あるサービスへの参照を別のサービスに渡すにはどうすればよいですか? 最初のサービスはステートフルになるため、未処理のリクエストを追跡できます。ただし、そのステートフル サービスのインスタンスが複数存在する可能性があります。では、どうすれば正しい応答を返すことができるでしょうか?

ServiceFabric のサンプルを実行できません。

Windows 8.1、VS 2015 Community Edition (管理者として実行) を使用しています。ServiceFabric SDK は既定の場所にインストールされます。

次のスタック トレースで FileNotFoundException を受け取ります。

この例外が発生してデバッグを停止すると、Service Fabric SDK システム トレイ アイコンから [ローカル クラスターのリセット] オプションを選択するまで、正常にデプロイすることさえできません。

サンプルでハードコードされたパスを探して、アンインストールと再インストールを試みました。

別のマシンでサンプルを実行することはできますが、これが私の主要な開発ボックスです。どちらの場合も、SDK である VS 2015 Community Edition をインストールしてから、サンプルを実行しようとしました。MSND フォーラムで提案されているように、ServiceFabric パスを PATH 変数の先頭に移動して、zip.dll という名前のファイルも競合しないようにしました。