@vasily-kirichenko Nice ;) but I raised this idea because of this message: "I may have to change my architecture approach a bit"
And after reading the question twice The OnPull would be non trivial, as I suspect the event/message is different in the sequence
GetTemp(); wait 250ms GetPowerLevels() wait another 15 minutes
I've been keeping with traditional Req/Resp for the webapi/webclient. It seems like the problem would be solved more appropriately if I changed to aysnc (SignalR). But, that's one of those "I can do that in a weekend" paths :)
Hello, I noticed that remote ActorSelection from a cluster node does not work the same way as when executed from a standalone app. From a Cluster node I am trying to remotely select an actor using fully qualified remote address with machine name, and selection resolution times out. But if I first create a new actor system and execute the same code with the same remote address from the newly created system it will works fine. Is there anything to be aware of when doing remote actor selection in a cluster?
@AndreSteenbergen that's pretty much it. But it's RecordTemp();wait 250ms;RecordPowerLevels(); and the events are recorded to EventStore with TempRecorded, and PowerLevelsRecorded. The hardware is my problem point because if a call is made while another is processing it'll either be ignored or worse cause the device to hang.
I think I would go for the simple version at this moment; call and wait. The actor won't process stuff if I am correct in the meantime
Np; just don't forget to place Self in a variable first, as the reference gats lost
I haven't used it, but if I am correct you can also use async methods in actors since 1.??.?? don't know the exact version
Can grouped routers take in fully qualified routees.paths to remote actors on a cluster?
I did that almost exactly in the job script. Would putting the delay in the actor's command handler have any ill effects I'm not considering?
Chandra Sekhar Manginipalli
So I can route the messages sent to this round-robin-group to an actor on a separate cluster. Tried something like routees.paths = ["akka.tcp://MyActorSystem@Machine:port/user/myactor"], but it throws "is not a valid relative actor path. Parameter name: routeesPaths"
The PipeTo method is what I recall is recommended; but both methods should work fine
I want better hardware to work with, but I'll settle for not breaking it in production :) But, yeah, this seems to be exactly what I need.
We have to work with, what we are given sometimes.
Chandra Sekhar Manginipalli
So far from what I searched, sounds like the routees have to be in the same ActorSystem as the router (independent of nodes) when using grouped routers. Anyone know if the routees can be on a different actorsystem?
does anybody know if "Reactive Applications with Akka.NET" is gonna be released, finally?
The last MEAP is rather outdated, it uses Helios in snippets, etc.
@vasily-kirichenko the publisher keep changing the release date
the new release date is Sep 30, 2018
@vasily-kirichenko afaik the author has no more interest in akka.net. The book will be hopefully finished after some foreword and minor update.
has moved to jvm maybe :)
no, he's working in CompositionalIT and last time I've checked, he was contributing to MBrace
Could you recommend how to integrate MVVM with Akka.NET?
always call Tell method of actor in Command Handler.
I must simply call the Tell method on all Command-Message handling functions.
This message was deleted
always. Is it right?
Are there another ways?
@hhko Tell is fire and forget, I.e. your command will be finished immediately, I suppose you want to trigger some action, maybe with some response and the button should be disabled during execution ? Then I would use Ask instead of Tell
If your command supports async execution ofc
@hhko I have used a combination of two actors with MVVM, a UI actor which is passed the instance of the view model in it's constructor and a service actor which does work in the background. View model commands use Tell to send messages to the service actor and pass the UI actor as the sender, so all responses from the service are handled by the UI actor which can safely set properties on the view model
@anthonyhawes why not just save the UI execution context and perform view model mutation in it?
I found out from prior trials that Hyperion has issues when a full framework actor has to communicate with a .net core framework actor. This means with the new version of akka.net we cannot have full framework apps sending messages to core akka app it sounds like. I will try to put together a test app with akka.net 1.8 and see how it behaves.
Specially when we have Dictionaries and IEnumerables.
Yes we encountered that issue too. Its either .Net Core everything or nothing. Unless you roll your own serializer