複数のStatefulService名前付きリスナーを持つFabricTransportServiceRemotingListenerタイプのレプリカリスナー

-1

基本的には、セカンダリレプリカから読み取ることができるようにします。だから私は、読み取り専用のリスナにlistenerOnSecondaryパラメータを持つ別の名前付きリスナを追加しようとしました。しかし、ローカルに展開すると、SFはこのステートフルサービスのインスタンスを作成できません。複数のStatefulService名前付きリスナーを持つFabricTransportServiceRemotingListenerタイプのレプリカリスナー

protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners() 
{ 
    yield return 
     new ServiceReplicaListener(context => new FabricTransportServiceRemotingListener(context, this), 
      "StatefulReadWriteCommunicationListener"); 
    yield return 
     new ServiceReplicaListener(context => new FabricTransportServiceRemotingListener(context, this), 
      "StatefulReadOnlyCommunicationListener", listenOnSecondary: true); 
}

出典

2017-02-09 alltej

セカンダリから読もうとしていますか？どのような問題を解決しようとしていますか？一般的に、セカンダリレプリカからの読み取りは実際には望ましくありません。セカンダリレプリカからの読み込みは、古いデータ（過去の一貫性のあるデータ）を表示できるだけでなく、まだクォーラムコミットされていないため、元に戻すことができます（false progress）。あなたがセカンダリーから読むことになっているのであれば、あなたが読んでいるものとあなたがその情報を使って何をしているのかに非常に注意する必要があります。 – masnider

私は、プライマリレプリカが読み取りと書き込みのためのものであり、セカンダリは読み取り専用であることをドキュメントから読み取ったと考えました。また、信頼できる辞書を使用して検索/ホットデータを保存するので、セカンダリレプリカで読み取りを行うと効率的です。では、いつ私は 'listenOnSecondary：true'を使うべきですか？ – alltej

効率的ですが、おそらく_correct_ではありません。あなたが読んでいる情報の一貫性に気にしない限り、今日はセカンダリから読むことはほとんどありません。あなたはセカンダリから読むことができますが、それはあなたが意味するものではありません。あなたは今日あなたが望むように説明する必要があります。たとえば、パフォーマンスの問題を解決しようとしているだけの場合は、おそらくサービスを分割して、読み取り/書き込みの一部が他のノードに最初に移るようにする方がよいでしょう。途中で最適化しないでください。 – masnider

第2リスナーのみを使用してください。 ServiceProxyの作成時に通信するターゲットレプリカを指定します。これはCreateメソッドのパラメータです。

上記の例では、2つの特定のエンドポイントを使用しています.1つはセカンダリ・レプリカとの通信を有効にし、もう1つは有効化しません。

出典

2017-02-10 06:03:34 LoekD

この2つのリスナーについて文句を言うように見えるので、このサービスのインスタンスを作成していないのが現状です。 – alltej

はい、最初のものを削除してください。 – LoekD

つまり、2人のリスナーを作成する必要はありません。しかし、私はプロキシを作成するとき、私はCreateメソッドで指定しますか？ – alltej

複数のStatefulService名前付きリスナーを持つFabricTransportServiceRemotingListenerタイプのレプリカリスナー

答えて

関連する問題