risorse in diretta in Akka flusso descrizione flusso

Question

c'è questa nota nel akka-stream docs precisando quanto segue:

... una descrizione flusso riutilizzabile non può essere vincolata alle risorse “dal vivo”, qualsiasi connessione o l'allocazione di tali risorse devono essere differito fino al momento della materializzazione. Esempi di risorse "live" sono già connessioni TCP esistenti, un editore multicast, ecc .; ...

ho diverse domande riguardanti la nota:

• A parte i questi due esempi, quali altri conteggi delle risorse come un live?
  • Tutto ciò che non può essere copiato in modo sicuro (profondo)? Come un Thread?
  • Devo anche evitare di condividere qualcosa che non sia thread-safe?
• Che dire di un ActorRef esistente nel ActorSystem utilizzato dal ActorFlowMaterializer?
• Come posticipare l'allocazione fino al momento della materializzazione? Ad esempio, è sicuro allocarlo nel costruttore di un PushPullStage ma non nella funzione di creazione di un FlowGraph?

Answer 1

Il problema qui è un problema comune se consideriamo i servizi Web, le connessioni RMI o qualsiasi altro protocollo di comunicazione. È sempre consigliabile condividere valori "primitivi" e riferimenti, poiché il marshalling/unmarshalling o serializzazione/unserializing è sempre un mal di testa. Pensa anche a diversi tipi di ambienti che comunicano tra loro. La condivisione di valori solidi è un modo sicuro per risolvere la comunicazione.

Akka di per sé è un buon esempio di "microservizi" che comunicano tra loro gli attori. Quando leggo la documentazione di Akka, una buona parola definisce molto bene gli attori di Akka. Gli attori sono come client di posta e puoi pensare che ogni cliente abbia una casella di posta. Quando passi una variabile, è come se avessi una nuova email.

Breve risultato di una lunga storia, evitare di condividere oggetti "dipendenti" che possono essere invalidati prima che vengano letti da un altro attore. Inoltre, se il tuo sistema nomina actorRef in modo dinamico, evita di chiamarli in base al suo riferimento.

"Materializzazione" è spiegato in documenti di akka-stream.

Il processo di materializzazione può essere parametrizzato, ad es. creazione di istanze di un progetto per la gestione dei dati di una connessione TCP con informazioni specifiche sull'indirizzo della connessione e le informazioni sulla porta. Inoltre, la materializzazione creerà spesso oggetti specifici che sono utili per interagire con il motore di elaborazione una volta eseguito, ad esempio per spegnerlo o per estrarre le metriche. Ciò significa che la funzione di materializzazione prende una serie di parametri dall'esterno e produce un insieme di risultati. La composizionalità richiede che questi due insiemi non possano interagire, perché ciò stabilirebbe un canale segreto attraverso il quale diversi pezzi potrebbero comunicare, portando a problemi di ordine di inizializzazione e guasti imprevisti del runtime.

Quindi utilizzare i parametri anziché passare "connessione" stessa.

Il rinvio di una risorsa dal vivo non è un grosso problema.Ciò significa che se si utilizza una connessione per tutto il sistema, è necessario mantenerlo sempre attivo. O quando si crea una transazione in actor-1 e la si invia a actor-2, non si deve terminare la transazione in actor-1 finché l'actor-2 non termina il suo lavoro con la transazione.

Allora come puoi capire? Quindi usi "Futuro" e "offerta()".

Spero di capire la tua domanda e spero di potermi esprimere.