|
|
|
|
Strumenti |
17-04-2017, 16:49 | #1 |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
Avete mai usato Akka.net?
Sembra un sistema interessante per fare un'applicazione altamente concorrente e distribuita, cosa ne penaste? L'avete mai usato?
Questo è il sito ufficiale: http://getakka.net
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
18-04-2017, 15:06 | #2 |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
La cosa forse più "sorprendente" è l'enorme quantità di documentazione, c'è addirittura una specie di "università":
https://petabridge.com/bootcamp ci sono però 2 cose che non ho capito: 1. E` possibile avere uno degli Actor che è anche un elemento GUI (Winform o WPF) cioè poter avere un Actor a cui io dico "mostra questo", "mostra quello" e che mi ritorna i dati che l'utente ha tabulato? Tra gli esempi ce ne è uno che usa Winform, ma usa il thread della GUI per creare l'intero ActorSystem (quello che si farebbe nel classico Main avviene nell'UI "Main") e un Actor separato per "comandare" la GUI. Questo approccio non funziona nel mio caso: non tutte le mie / nostre applicazioni necessitano di una GUI quindi vorrei che l'applicazione partisse da linea di comando e solo se "configurata" lanci la GUI 2. Come si interopera con Entity Framework? Anche qui io penserei ad un Actor che si occupa di questo e che chiamerei con molta fantasia "Storage" Nella loro visione uno potrebbe pensare di avere un "router" e una 50ina di questi Actor, così da poter "servire" più Actor contemporaneamente ma - stranamente - Entity Framework non è thread safe (come è possibile ?)
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
18-04-2017, 17:40 | #3 | ||
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
Quote:
Questo è l'esempio di cui parlavo: https://github.com/petabridge/akka-b...son1/README.md ma come ti diceva a me non andrebbe bene creare la GUI quando parte l'applicazione: non sempre ho la GUI Quote:
Spero di sì se no per il mio uso è poco utile, direi che in ogni caso deve essere solo 1 Actor a "parlare" con il DB gli altri devono inviarli Messaggi tipo "Fai questo", "Dammi questo"... Stasera ci gioco ancora un po'
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
||
19-04-2017, 09:46 | #4 | ||
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
Quote:
1. Con Ask() chiedo al Actor Storage di eseguire uno Statement (Select, Insert, Update...) 2. Storage analizza il messaggio ed esegue la query corrispondente con LINQ si "crea" dal nulla l'oggetto e lo si spara come risposta 3. Il Processo richiedente "ritorna" da Ask() che è una chiamata sincrona e procede a fare qualcosa con i dati ottenuti Mi confermi che Entity Framework non è thread safe vero? Quindi 2 Actor non possono richiedere di fare Insert nemmeno su 2 tabelle separate nello stesso istante? Mi chiedo se varrebbe la pena di usare NHibernate o qualche cos'altro il fatto di non poter usare i thread col DB è il punto debole dell'applicazione "distribuita" che usiamo ora fatta in C: sqlite non è thread safe e quindi abbiamo una sola applicazione che si occupa di "serializzare" (nel senso che li esegue in serie ) tutti i comandi verso il DB questo ci è quasi sempre andato bene finché abbiamo avuto la necessità di fare INSERT di 100'000 righe tutte in una botta e lì ci siamo potuti scordare con il C solo di provare ad allocare un json con 100'000 elementi e poi trasferirlo allo Storage per fare la INSERT: il resto dell'applicazione era bloccato! A quel punto - con la coda tra le gambe - abbiamo dovuto fare kludge piuttosto orrendi database "privato" dell'applicazione che poveraccia si deve caricare 100'000 righe e fare 100'000 INSERT e poi quando ha finito comando "ATTACH" allo Storage... uno schifo Quote:
Ecco come ho fatto: Codice:
[STAThread] //optional protected static bool StartUILoop() { Application.Run(); return true; } protected override void PreStart() { /* Let's start an Empty UI Application, the true Application will load the page with "Loading..." */ //Task mytask = Task.Run(() => Application.Run()); Task mytask = Task.Run(() => StartUILoop() ); } Codice:
var form = new LoginForm(); form.ShowDialog(); 1. MessageBox 2. Menu 3. Scrivere su uno o più field di una "pagina" caricata 4. Far ritornare tutti i dati di input inseriti dall'utente (sono un po' sorpreso che non esista un metodo di "Form" che lo faccia automaticamente!) Devo studiare se si riesce a caricare un elemento GUI dato il nome e poi sono a cavallo
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! Ultima modifica di fano : 19-04-2017 alle 09:49. |
||
20-04-2017, 10:25 | #5 | |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
In realtà funzionava sì, ma ShowDialog() blocca l'Actor finché non viene chiusa la form!
Visto che - per ora - manco la chiudevo funzionava finché non ho implementato la chiusura pulita e l'Actor "UI" non voleva uscire! Che fessacchiotto Peccato che ora sono fregato: 1. Ho provato a fare una Dialog Async viene mostrata correttamente e l'Actor può fare altro nel frattempo, ma quando premo "OK" sulla Dialog l'Actor viene fatto secco e il parent riceve l'evento da un Actor di sistema "DeadLetter" e sì e muore pure lui 2. Ho provato a far girare l'Actor nello stesso contesto della GUI alla fine sembrava pure che ci fossi riuscito, ma la GUI manco appare e mi becco un orripilante eccezione: Quote:
Sto sbagliando strada è evidente non posso "manipolare" così l'UI thread di Windows facendolo partire in un momento "a caso", quando muore l'Actor lo ricreerebbe, se ne ho 2 di GUI dovrei farne 2? Non credo sia permesso / corretto
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! Ultima modifica di fano : 26-04-2017 alle 09:58. |
|
20-04-2017, 17:22 | #6 |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
Il problema è che Windows trova "anormale" fare un'Applicazione senza GUI infatti l'entry point di Winform è "Application", un applicazione command line te la fa fare ma un "ibrido" è - evidentemente - un anti pattern!
Di fatto il modo corretto è quello consigliato da mamma Microsoft Application.Run() è l'ultima istruzione nel Main() (che infatti ti blocca) farlo partire dentro l'Actor è un'anti pattern: https://github.com/akkadotnet/akka.net/issues/2624 nella visione AKKA poteva non essere un problema anche se crashava la GUI la loro filosofia è "let it crash" bastava metterci un una SuperVision strategy per far ripartire la GUI, fare Application.Exit() nello stop e poi rifare poco dopo Application.Run() chissà come avrebbe gradito! Un po' mi rompe il "giochino" questo...
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
21-04-2017, 09:51 | #7 | |
Senior Member
Iscritto dal: Oct 2005
Messaggi: 3305
|
Quote:
Non ho capito però la tua esigenza, vorresti scrivere un codice unico e fare in modo che funzioni sempre a prescindere se sia una console o una GUI? |
|
21-04-2017, 13:02 | #8 | |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
La mia applicazione sarebbe modulare quindi alcuni "Actor" esisterebbero sempre, ma altre cose no per esempio se l'applicazione richiede un operatore che faccia cose e/o visualizzare un Interfaccia di altro tipo allora un UIActor esiste altrimenti non c'è nessun GUI, analogamente al caso in cui se ho una stampante faccio partire un PrinterActor che apre la seriale altrimenti - la seriale - resta bella chiusa
Comunque l'eccezione che ottengo non la capisco proprio ora dovrei farlo come "piace a Windows": 1. Faccio Application.Run() nel Main (lancio però un task perché se no non posso fare altro) 2. Creo l'ActorSystem 3. Creo gli Actor quelli che "esistono sempre" 4. Uno di questi Actor che è il manager / supervisore dei dispositivi crea l'Actor che dovrà interfacciarsi con la GUI avendo l'accortezza di crearla nello stesso thread ... e non va una fava! La creazione dell'Actor fallisce miseramente con la coda tra le gambe: Quote:
In questo lungo week end farò altre prove sarà qualche sciocchezza di sicuro
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! Ultima modifica di fano : 26-04-2017 alle 09:59. |
|
24-04-2017, 17:56 | #9 |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
Sembra abbastanza inusabile purtroppo:
1. Creare un Actor nella GUI significa che lo trovi create dentro la GUI dentro l'evento Load, questo per me è inacettabile: si rompe il rapporto padre / figlio che avevo pensato 2. Tentare "truschi" come fare Application.Run() in a Task così da poter creare gli Actor bello paciarotto come piace a me non funziona: il Driver della GUI non viene creato usando come "scusa" che non c'è nessun UI thread! Evidentemente usando un Task Application è in un altro thread rispetto a quello solito e quindi mi frega... 3. Mostrare le Form con ShowDialog() funzionicchia, ma è un accrocchio devastante... e non posso avere una MainWindow (ci ho provato: pigio un bottone e il messaggio viene mandato da un "morto" ) Peccato!
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
26-04-2017, 09:58 | #10 |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
Allora ho raggiunto un compromesso (con me stesso: sono i compromessi peggiori ) ho reso "System" globale nel mai creo solo 2 high level actor su 3, quello dei device (la GUI per ora) viene creato dentro Application.OnLoad() così può - a sua volta - create l'Actor "driver" della GUI vera e propria.
Non mi piace molto (anzi mi fa un po' schifo ) visto che così il DeviceManager che doveva funzionare per tutti i device è "vincolato" alla GUI, forse un'altra possibilità era di NON creare il driver della GUI in PreStart di DeviceManager, ma fare solo quello dentro Application.OnLoad(), ma mi sa che si "piantava" lo stesso! Altro "compromesso" quando viene premuto un bottone su una form non posso fare direttamente DeviceManager.Tell() perché facendo così il sender risulta "DeadLetter" e DeviceManager che una logica per rilevare i figli non... gradisce! Il "trusco" è che ogni elemento della UI ha un altro costruttore a cui è passato l'ActorRef del driver UI a cui manda un messaggio, il driver UI non fa altro che spararlo al manager senza toccarlo... Questo ha un parziale vantaggio (forse) potrei evitare di creare un messaggio troppo complesso dentro la GUI e far fare il lavoro "sporco" al Driver, ma girando nello stesso thread e con lo stesso dispatcher mi sa che - alla fine - cambierebbe ben poco!
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 13:48.