Es gibt diesen Hinweis in der akka -stream-Dokumente mit folgenden Angaben:
... eine wiederverwendbare Flussbeschreibung kann nicht an "lebende" Ressourcen gebunden werden, jede Verbindung oder Zuweisung dieser Ressourcen muss bis zur Materialisierungszeit zurückgestellt werden. Beispiele für "Live" -Ressourcen sind bereits bestehende TCP-Verbindungen, ein Multicast-Publisher, etc .; ...
Ich habe einige Fragen bezüglich der Notiz:
Thread ? ActorRef in der ActorSystem , das von ActorFlowMaterializer verwendet wird? PushPullStage zuzuordnen, aber nicht in der create-Funktion eines FlowGraph ? Das Problem ist ein häufiges Problem, wenn wir Webservices, RMI-Verbindungen oder ein anderes Kommunikationsprotokoll betrachten. Es wird immer empfohlen, "primitive" Werte und Referenzen zu teilen, da Marshalling / Unmarshalling oder Serialisierung / Deserialisierung immer ein Problem darstellt. Denken Sie auch an verschiedene Arten von Umgebungen, die miteinander kommunizieren. Das Teilen solider Werte ist ein sicherer Weg, die Kommunikation zu lösen.
Akka selbst ist ein gutes Beispiel für "Microservices", die Akteure miteinander kommunizieren. Wenn ich die Dokumentation von Akka lese, definiert ein gutes Wort Akka-Schauspieler sehr gut. Akteure sind wie Postfach-Clients und Sie können sich vorstellen, dass jeder Client über ein Postfach verfügt. Wenn Sie eine Variable übergeben, erhalten Sie eine neue E-Mail.
Kurzes Ergebnis der langen Geschichte, vermeiden Sie "abhängige" Objekte zu teilen, die ungültig gemacht werden können, bevor sie von einem anderen Akteur gelesen werden. Wenn Ihr System aktorRefs dynamisch benennt, vermeiden Sie es außerdem, sie über die Referenz aufzurufen.
"Materializing" wird in Doks von akka-streams erklärt.
Der Prozess der Materialisierung kann parametrisiert werden, z. Erstellen eines Blueprints für die Verarbeitung der Daten einer TCP-Verbindung mit spezifischen Informationen über die Adresse und die Port-Informationen der Verbindung. Darüber hinaus werden durch die Materialisierung häufig bestimmte Objekte erstellt, die für die Interaktion mit der ausführenden Verarbeitungs-Engine nützlich sind, beispielsweise zum Herunterfahren oder zum Extrahieren von Metriken. Dies bedeutet, dass die Materialisierungsfunktion eine Reihe von Parametern von außen übernimmt und eine Reihe von Ergebnissen erzeugt. Die Kompositionalität erfordert, dass diese beiden Mengen nicht interagieren können, da dies einen verborgenen Kanal zur Kommunikation verschiedener Teile darstellen würde, was zu Problemen der Initialisierungsreihenfolge und undurchschaubaren Laufzeitfehlern führen würde.
Verwenden Sie also Parameter, anstatt "Verbindung" selbst zu übergeben.
Das Verschieben einer Live-Ressource ist keine große Sache. Das heißt, wenn Sie eine Verbindung für alle Systeme verwenden, sollten Sie sie immer am Leben erhalten. Oder wenn Sie eine Transaktion in actor-1 erstellen und an actor-2 senden, sollten Sie die Transaktion in actor-1 erst dann beenden, wenn actor-2 seinen Auftrag mit der Transaktion beendet hat.
Wie können Sie das verstehen? Dann verwendest du "Future" und "offer ()".
Ich hoffe, ich verstehe Ihre Frage und hoffe, dass ich mich ausdrücken kann.
Tags und Links scala java akka akka-stream