These are chat archives for akkadotnet/akka.net

13th
Nov 2015
Thomas Lazar
@thomaslazar
Nov 13 2015 07:08
is there a way to "re-appropriate" hocon to set a property of an actor when it gets created? or to just read it out myself so i can configure the actor when it gets created?
Roger Johansson
@rogeralsing
Nov 13 2015 08:56
@Horusiath akkadotnet/akka.net#1400 .. isnt the semantics just that we need to prevent a specific envelope from being stashed more than once?
each envelope can only be dequeued once from the mailbox, if we get multiple tells with the same message instance, that will be wrapped in a unique envelope per tell, so IMO, it looks like we only need to prevent stash from being called more than once per actor run
Bartosz Sypytkowski
@Horusiath
Nov 13 2015 09:17
@rogeralsing if we have test in our specs for that (I hope we have) I'm all for that. Our problem is not envelopes equality but preventing duplicate stashing
and when it comes to Wire and immutable collections - I think we should ping MS team responsible for that and suggest them to create a standardized way of deserializing immutable collections on their side. Right now every framework I seen hacks this through reflection code working specifically for immutable collections alone
Thomas Tomanek
@thomastomanek
Nov 13 2015 10:58
hey all. So, I'm trying to test a PersistentActor sycnrhonously by specifying a CurrentThreadDispatcher, but for some reason it's not working. It does work with a regular ReceiveActor however, so I'm assuming the PersistentActor is introducing some other sort of concurrency...can anyone shed any light?
hmm ok actually I think it might be because the actor is still recovering
Thomas Tomanek
@thomastomanek
Nov 13 2015 11:52

me again. So I'm trying to test that on receiving a particular message the actor throws out of the handler (expecting in real life that the parent will apply it's directive). I've initially got the following, which I thought would work, but isn't. Can someone suggest a better solution or shed some light on why this isn't working please?

[Test] public void test_actor_dies_on_some_message() { var died = false; var actor = this.ActorOfAsTestActorRef<MyActor>(Props.Create(() => new MyActor()).WithDispatcher(CallingThreadDispatcher.Id) .WithSupervisorStrategy(new OneForOneStrategy(e => { died = true; return Directive.Stop; }))); actor.Tell(new SomeMessage(new Exception("noooooooooo"))); Assert.IsTrue(died); }

ugh that didn't format well
oh btw forget that it's a testactorref, doens't need to be
Roger Johansson
@rogeralsing
Nov 13 2015 13:08
@sadprofessor WithSupervisorStrategy is the supervisor strategy that is applied to that actors children, not to the actor itself
Thomas Tomanek
@thomastomanek
Nov 13 2015 13:09
ohhh, oops that was a fundamental misunderstanding of something I've been using in prod for ages :-|
oh no wait, yeah ok I know that heheh. Ok fine so I see why it's not working in this case
do you think there's a decent way to do this test?
Thomas Tomanek
@thomastomanek
Nov 13 2015 13:18
ok I created a temporary parent actor to define the supervision strategy on and that works
Roger Johansson
@rogeralsing
Nov 13 2015 13:21
yes, a temp parent actor is the way to go, you can make the parent actor act as some sort of factory too, you can inject it with a lambda or whatever to tell it how to produce the child, so that the temp parent is reusable
Thomas Tomanek
@thomastomanek
Nov 13 2015 13:26
@rogeralsing yeah good call, cheers
Weston
@ronnyek
Nov 13 2015 15:45
sorry I'm not trying to ask you guys to tell me why akka..net is better than orleans, but I'd ultimately like to know what sort of systems orleans might be better for than akka etc
like understand their differences, so I choose the right one for my project
Bartosz Sypytkowski
@Horusiath
Nov 13 2015 17:44

@ronnyek to be honest I think, this is more matter of what kind of people team is made of and specifics of the problem, you're trying to solve.

Of course while both Akka.NET and Orleans cover similar fields, some of them are more towards one technology than other i.e. data analytics and high-performance computing for akka while orleans more for scaling out business domain logic with low consistency constraints - at least at the present moment, until cluster-sharding is not ready. And I'm a "little bit" biased, but from my perspective akka is superset of orleans, because it has lower baseline, which allows making more things possible, and extensible so higher levels of abstraction can be just plugged on top of library. Eventually all features of orleans (even project orleans itself) could be implemented in akka - but not vice versa.

However how does this maps to first sentence? In general akka.net gives you more control, it's more toolkit that allows you to build your own "framework" accordingly to your needs - when working with it, you're actually building your own abstraction layer on top of it. But this also enforces more responsibility from the team and ability to program in paradigm that is not inherently OO. And this requires an understanding of problems and solutions in domain of distributed computing and actor paradigm itself. Orleans is proud of it's low barrier of entry - but I would call this AngularJS paradox ;) Also each framework has some tradeoffs and limitations - you need to understand how well does it fit in your case, because at some point you may hit the barrier, that framework you use, was not prepared for.

Weston
@ronnyek
Nov 13 2015 18:01
thanks for input
Aaron Stannard
@Aaronontheweb
Nov 13 2015 18:11
@rogeralsing @Horusiath so there's been a steady chorus of enterprise users asking for Strong Naming support coming through @skotzko and I's mailbox
I've been long opposed to it
but it's clear to me that it's a real pain point for people we would love to have as production users
is this something we want to solve at the level of the OSS project?
our previous position has been to tell the users to do it themselves
do we want to stick with that or are you guys open to reconsidering it? I'm at a point where I'm open to the possibility. I'm torn though because I know it might potentially be a pain in the ass for things that come up in the real-world like module downgrades and dependencies
Aaron Stannard
@Aaronontheweb
Nov 13 2015 18:17
what do the people in this Gitter room think?
Roger Johansson
@rogeralsing
Nov 13 2015 18:28
I guess we could add a separate set of strong named assemblies on nuget, also, there are tools like this that might solve the problem (?) https://github.com/dsplaisted/strongnamer
Aaron Stannard
@Aaronontheweb
Nov 13 2015 18:29
oh god that is genius
I love it lol
Aaron Stannard
@Aaronontheweb
Nov 13 2015 18:35
the separate NuGet packages idea is something I can get onboard with
the real pisser is having to strong name all of the things Akka.NET depends on
Helios, DotNetty, Wire, all of the Akka.Persistence db drivers
has to be strong-naming all the way down
Roger Johansson
@rogeralsing
Nov 13 2015 18:38
protobuf and json.net are already strongnamed arnt they?
Aaron Stannard
@Aaronontheweb
Nov 13 2015 18:39
I know JSON.NET is
not sure about protobuf
have no idea about the F# assemblies either - FsPickler
Roger Johansson
@rogeralsing
Nov 13 2015 18:41
FsPickler can be ditched soon. Wire can serialize linq expressions too and thats the only thing we use fspickler for
Aaron Stannard
@Aaronontheweb
Nov 13 2015 18:42
got it
DotNetty will be strong named
MSFT requires it IIRC
although I'd been asking them not to lol
Roger Johansson
@rogeralsing
Nov 13 2015 18:44
I think we are in a better position than e.g. Json.NET when it comes to strong naming, as very few libs/frameworks will have dependencies on Akka.NET, its most likely applications only that referene us
Aaron Stannard
@Aaronontheweb
Nov 13 2015 18:45
true
one day we might see someone write some cool infrastructure-type frameworks on top of Akka.NET
Roger Johansson
@rogeralsing
Nov 13 2015 18:45
so I guess/hope, the version problems that come with strong naming will not affect us as much... (if we were to just strongname all of it and not provide non strongnamed assemblies)
Aaron Stannard
@Aaronontheweb
Nov 13 2015 18:45
ala Spark for JVM Akka
but strong naming won't affect something that big
yeah, I agree with that
I'm more worried about the layer underneath us
getting all of those Akka.Persistence plugins strong named
I'm sure some of those DB drivers are already strong-named
but I don't want to be a "strong naming ambassador" for all of those projects :p
and then in the future, dealing with downstream upgrades
i.e. someone wants to update a DB driver that wasn't built against the version of Akka.Persistence they're using
well, I guess strong naming wouldn't prevent that would it?
wouldn't it just add a binding redirect?
Roger Johansson
@rogeralsing
Nov 13 2015 18:48
json.net says in their blog that they dont update version numbers of their assemblies at all unless it is a major V. just to skip the strongnaming issues
Aaron Stannard
@Aaronontheweb
Nov 13 2015 18:50
my mood as I think about upgrading our build process to support strong naming:
:satisfied: :smile: :smirk: :worried: :sweat: :cry:
Christian Duhard
@cduhard
Nov 13 2015 18:51
I'm in pain just reading along
Christian Duhard
@cduhard
Nov 13 2015 19:28

can anyone explain this json

"AccountId": {
"$": "I13244"
}

its just an int, but it gets serialized like that
Roger Johansson
@rogeralsing
Nov 13 2015 20:01
yes, Akka.NET needs to know what type each value has so that it can deserialize back to the correct type.. Json is pretty much untyped, json does not say if a number is an int32, int64, float or double.. when we pass Props and other primitives that contains arrays of object, we need to know the type
e.g one example where we had problems earlier is in remote deployed acotrs constructors, if you passed an int32, it would deserialize as an int64 as the ctor args is just an object array
Aaron Stannard
@Aaronontheweb
Nov 13 2015 20:12
@/all this post took a ton of work from @skotzko, but now it's finally done https://petabridge.com/blog/akka-testkit-introduction/ - everything you ever wanted to know about unit testing Akka.NET actors using Akka.TestKit. Includes fun stuff like virtual time scheduling and the EventFilter
we'll be putting the information from that post into the http://getakka.net/ docs soon also
Christian Duhard
@cduhard
Nov 13 2015 20:16
@rogeralsing gotcha. I am trying to work with these events in EventStore via javascript
Timur Babyuk
@timba
Nov 13 2015 20:16
Very useful post @skotzko , thanks!
Aaron Stannard
@Aaronontheweb
Nov 13 2015 20:18
I learned a bunch of new stuff about the TestKit as a result of his research - lot more tools inside it than I had realized
I'd never really used TestProbe or TestActorOf, for instance
adospace
@adospace
Nov 13 2015 20:45
Guys you are among the most talented programmers I know; it's unbelievable how Akka.Net works great: we're completely rewriting a big SCADA project here using it, just a BIG thank you (btw just bought the ebook )
John Nicholas
@MrTortoise
Nov 13 2015 22:33
hmm what do i misunderstand ... i am using ActorOf and getting a named actor. I then poison pill and wait on the terminated message. Then later i attempt to use ActorOf with the same name and get an exception saying that actor name already in use. Is that expected behaviour? Does that imply i should be adding some kind of counter/randomness into my naming?
Aaron Stannard
@Aaronontheweb
Nov 13 2015 22:46
@MrTortoise no, that name should be free
expelled from the ChildActorContainer
Andrew Skotzko
@skotzko
Nov 13 2015 22:48
@timba thanks! glad it’s helpful
Aaron Stannard
@Aaronontheweb
Nov 13 2015 22:49
@adospace you're too kind - thanks for buying the book!
John Nicholas
@MrTortoise
Nov 13 2015 22:55
@Aaronontheweb ok thanks, adding a sleep made the test case work. keep getting tripped up with test code being really synchronous not giving the actor system tiem to do anything. Think i might try making tests actors see how that works out - might be quite a nice use for TestActorOf as then can assert against its state.
Aaron Stannard
@Aaronontheweb
Nov 13 2015 22:56
@MrTortoise yeah, that's an issue with writing unit tests for actors - the tests are executed synchronously for a framework where everything is asynchronous
John Nicholas
@MrTortoise
Nov 13 2015 22:59
@Aaronontheweb @adospace which book?
Aaron Stannard
@Aaronontheweb
Nov 13 2015 23:00
@MrTortoise the Akka.NET Bootcamp eBook - it's the same material as the free online course but delivered in Kindle-friendly / .mobi formats
we offer it at the very bottom of the bootcamp page: https://petabridge.com/bootcamp/
John Nicholas
@MrTortoise
Nov 13 2015 23:01
ahh cool, that's great material. Helped me a ton - and is a good reference. Thanks