These are chat archives for akkadotnet/akka.net

31st
May 2017
fanoI
@fanoI
May 31 2017 18:52
I continue to have problems deploying a GUI Actor remotely... I've tried to do things simpler (without routers I don't need them) so I've done as this example: http://getakka.net/docs/remoting/deployment and continue to not work! The strange thing is that I got exception when the children of the remote deployed actor is created but the expection is logged in system1 console! IMHO the exception is wrong as yes system1 has no UI "context" but system2 surely has:
[ERROR][31/05/2017 18:50:29][Thread 0006][akka://system1/user/uiactor] Configuration problem while creating [akka://system1/user/uiactor/UIBackend] with dispatcher [akka.actor.synchronized-dispatcher] and mailbox []
Cause: [akka://system1/user/uiactor#367342565]: Akka.Actor.ActorInitializationException: Exception during creation ---> Akka.Configuration.ConfigurationException: Configuration problem while creating [akka://system1/user/uiactor/UIBackend] with dispatcher [akka.actor.synchronized-dispatcher] and mailbox [] ---> System.InvalidOperationException: Non è possibile usare SynchronizationContext corrente come TaskScheduler.
Arjen Smits
@Danthar
May 31 2017 19:13
Remote deploying actors that run on the UI thread. Will not work. We dont support it, because its impossible.
Your best bet is to utilise an actor that runs on the client, inside the ui thread. Using dispatcher settings. That actor would act as an proxy to the rest of your actor system.
So you want to do something from your UI ? You send a message to that UI actor, which will process it right then and there, or forward it to other actors that run in your actor system (and not on the UI thread)
Arjen Smits
@Danthar
May 31 2017 19:20
The only reason you want to run an actor on the UI thread is because you want to automatically marshall messages back to the UI thread.
What you often see, is that a Form is simply created by an actor, that runs on the UI thread.
that way each form is its own actor
sending and receiving messages, and updating stuff on your form becomes dead easy that way
Anders Storhaug
@andersstorhaug
May 31 2017 21:13
With ClusterSharding, should dependencies be passed via props/messages? As a made-up example IFileReader -- something that is probably not serializable. What are some nice workarounds for that? Inheritance comes to mind... BaseReaderActor, FileReaderActor, TestReaderActor that has a paramless ctor, calls base ctor with an IFileReader impl. Suggestions?
Aaron Stannard
@Aaronontheweb
May 31 2017 21:16
@andersstorhaug IMHO
I'd have each entity send a message to some actor
who in turn tells the entity actor what file it should process
and then it can open its own FileReader
without knowing more about the specifics, that's the type of design I would engage in
Anders Storhaug
@andersstorhaug
May 31 2017 21:22
Specifically, this is for batch file processing, say a file with 100K requests in it. Currently I'm working with an "processor" actor-per-file, but there's enough logic in there, that I'd like to split the file access impl. out, and use line-index as ID. Mostly because I know that at some point in the future, I'm going to need to change how file-access works (eg. store lines in a DB, or compress on FS, etc)
and also I'd like to test the processor logic without having to access a physical file system
Aaron Stannard
@Aaronontheweb
May 31 2017 21:22
I see
have you taken a look at Akka.Streams?
it has some built-in tools for turning File.IO into an event stream
Anders Storhaug
@andersstorhaug
May 31 2017 21:24
Here, processors are what I'm using cluster-sharding for, as they're persistent. Processing can take a very long time, eg. 18h, need to survive service restart
Aaron Stannard
@Aaronontheweb
May 31 2017 21:25
oh wow
got it
in that case yeah
cluster.sharding is the way to go
each one of those actors can use a stream for working through the file itself though, as long as you have a way of telling the source a starting position
Anders Storhaug
@andersstorhaug
May 31 2017 21:26
Have looked into that a little bit -- though unfortunately I do need some amount of redundancy in place - haven't figured out how I'd use Akka.Streams in a clustered env. Though Streams back-pressure is enticing, right now I'm doing something along the lines of the old school hand-rolled Actor back pressure kind of thing
Aaron Stannard
@Aaronontheweb
May 31 2017 21:27
so you can think of this as a "local" stream
one per file
and the entity actor who writes out whatever the processed output was can be your sink
but anyway, it's a moot point if you have something up and running that you like
not going to tell someone to throw away code that they're happy with for something they've never used before :p
Anders Storhaug
@andersstorhaug
May 31 2017 21:29
Ah, well, the other complex part of this... is that each file contains requests for different endpoints (many endpoints). I need backpressure to work on a per-endpoint level. Though yeah, I think at this point are definitely workable for what I'm doing. Still going to keep Akka.Streams in the toolbox
Aaron Stannard
@Aaronontheweb
May 31 2017 21:30
I feel you there man
I wrote a tool with Akka.NET a few years ago that serialized 100% of HTTP traffic to one of my ASP.NET MVC applications to a series of files
all of the live request data going into a super busy web API
wrote another tool in Akka.NET that took those requests, deserialized them, and fuzzed the root URL
Anders Storhaug
@andersstorhaug
May 31 2017 21:31
because that's what I've been thinking as well - Akka.Streams locally, hosted by clustered nodes. But -- the actual request is performed by another system, which calls back upon completion. So, that's maybe a bit of non-standard Streams stuff as well
Aaron Stannard
@Aaronontheweb
May 31 2017 21:31
so I could load-test my development cluster with production-style traffic patterns
used it to reveal a bug in Apache Cassandra that was crashing our system
that we couldn't replicate at all with the simulator we'd be using for years
wish I had OSSed that!
Anders Storhaug
@andersstorhaug
May 31 2017 21:32
That's a really good idea, actually it's funny, this system effectively being a batch-file API for a realtime system. Really works well to expose issues that you usually only see in production, under load :)
Aaron Stannard
@Aaronontheweb
May 31 2017 21:33
I got the idea originally from an article I read on how they test new versions of MMORPGs
the author, who had worked on Diablo 2 / Starcraft and then founded the company that started GuildWars
said the only safe and reliable way to do it was to take a saved game file and replay it over the new code
to account for all of the human factors that you can't easily write automated tests for
revealed to us that we had one customer sending in some input that, while technically valid, produced a corrupt column name in Cassandra
and the error should have been caught at the driver level, or at the input validation level
but was only being trapped by a debug assertion running inside the actual file system engine inside Cassandra itself
Anders Storhaug
@andersstorhaug
May 31 2017 21:37
After this project, definitely going to keep this approach to testing in mind. This is replacing an existing batch system that has the same file format, so I have production data that I can use OOTB. Can't think of a better way to test it
But - just now working on transitioning it to Akka.NET. Actor concurrency model really simplifies the impl
Aaron Stannard
@Aaronontheweb
May 31 2017 21:38
glad to hear it!
this was the blog btw
hasn't been updated in a few years
but if you're into video games and programming, it's a real treat
Anders Storhaug
@andersstorhaug
May 31 2017 21:39
ah, was just about to ask. Thanks!
Aaron Stannard
@Aaronontheweb
May 31 2017 21:39
especially if you're a fan of the classic blizzard games like Warcraft / Starcraft / Diablo
his posts on the history of Diablo II and how it came into existence is really great
Anders Storhaug
@andersstorhaug
May 31 2017 21:41
Definitely - have actually been here now that I look at it. Have some more reading to do
fanoI
@fanoI
May 31 2017 22:03
@Danthar but do you have the sample code in my issue? I "deploy" remotely a normal Actor that - in turn in his PreStart() - method creates the UI Actor... this does not work too? I've added a sample code in the issue: akkadotnet/akka.net#2624