2

返信の概念を直接サポートしていない外部メッセージング システムとの統合を処理する Akka 1.3 コードがあります。コードベースを Akka 2.0 にアップグレードしようとしていますが、問題が発生しています。これは、既存の設計が ConcurrentHashMap にキーを生成し、senderFuture を使用してクリーンアップすることで「応答」メカニズムをシミュレートすることに依存しているためです。

ディスパッチを処理しているアクターに送信されるメッセージは、応答を期待している場合とそうでない場合があります。また、応答を期待している場合でも、ネットワークを介して送信された後、応答が得られない場合があります。結果として、HashMap は実際に返信が必要なメッセージ (伝えるのではなく尋ねる) のエントリのみを格納する必要があり、返信を受信しなかったエントリを一掃するための何らかの形式のクリーンアップ メカニズムが必要です。

Akka 1.3 では、senderFuture にアタッチすることでこれを行っているため、メッセージを送信したアクターがタイムアウトして応答をあきらめると、HashMap の対応するエントリも削除されます。

if (self.senderFuture().isDefined) {
  pendingRequests.put(replyToKey, sender)
  self.senderFuture().get.onComplete( f => {
    pendingRequests.remove(replyToKey)
  }
}

Akka 2.0 では、senderFuture へのアクセシビリティが削除されたので、このシナリオをきれいに処理する方法はありますか? それとも、ゼロからクリーンアップ プロセスを作成する必要がありますか?

4

1 に答える 1

2

あなたが探している正確な機能は、Akka 2.x には保持されていません。

  • リモートでのアクターのコミュニケーションが脆弱になり、
  • それは、より明確であるべきであるコミュニケーションで非自明なサイドチャネルを開きました。

を使用senderFutureするとは、クリーンアップ アクションの選択をクライアント アクターの責任にすることを意味します。メッセージの送信方法にこの情報を入れるのではなく、送信するメッセージにこの情報を含めるだけで、これを行うことができます.

考慮すべきもう 1 つの点は、2.0 で追加されたDeathWatch機能です。クリーンアップが必要であることを通知すると、ターゲットはcontext.watch()リクエストの送信者になり、対応するTerminatedメッセージが受信されたときにクリーンアップできます (送信者の死によってトリガーされます)。その後、クライアントは、適切なタイムアウトを指定して依頼パターンを引き続き使用できます。これにより、時間指定された関心の喪失がサービング アクターに返されます。

于 2013-01-08T13:08:14.120 に答える