These are chat archives for akkadotnet/akka.net

12th
Jun 2018
nathvi
@nathvi
Jun 12 2018 13:55
So, I've been researching, a message broker serves as a router and or a message translator.
nathvi
@nathvi
Jun 12 2018 14:25
Is there a way that an actor can receive messages from a non actor?
Anton Tcholakov
@anton-pt
Jun 12 2018 15:01
I suspect the answer is no, but is it possible to achieve synchronous rendezvous semantics across async boundaries in an Akka.Streams pipeline? You can set the input buffer to 1, but really, what I would like is input buffer 0, and for the source to only continue once the sink has processed the message.
nathvi
@nathvi
Jun 12 2018 15:09
@Aaronontheweb , your article on large messages and Sockets in Akka.NET was very informative.
me-slove
@me-slove
Jun 12 2018 15:10
@nathvi this is kind of an answer but I'm not sure of your use case. I mean why have an actor system and then not use it's capability? https://github.com/mikebridge/AkkaSignalR/blob/master/src/EchoAPI/Hub/EchoHub.cs
nathvi
@nathvi
Jun 12 2018 15:12
@me-slove , I'm not sure that I fully understood what akka can do. I didn't think it could use udp as a transport.
Chandra Sekhar Manginipalli
@leo12chandu
Jun 12 2018 15:16
@nathvi - About "Is there a way that an actor can receive messages from a non actor?" - If your actorsystem is using remote or cluster provider, then someone outside of that actorsystem/cluster can either use ClusterClient to send a message to this actor. Or you can directly use ActorSelection and send a message to this remote actor. Is your requirement something else?
nathvi
@nathvi
Jun 12 2018 15:21
@leo12chandu , I was under the impression that akka couldn't use udp as a transport, and was asking if there was a way to send akka messages to actors via some other non akka client to compensate for this
but akka can use udp as a transport, right?
me-slove
@me-slove
Jun 12 2018 15:21
@nathvi , So you want to receive a udp "message" and somehow route it to a specific actor? If so, write a top level actor that just sits waiting for a udp message and then call Tell to send it on to the appropriate router or actor. The only thing is the tell requires a valid sender so just send the top level actor. here's an example: ImporterService.SavePublisher?.Tell(new HubSaved(row), ImporterService.SavePublisher);
Importer is not an actor but calls in to the top level actor to inject the hubsaved (in this case to distributed pub/sub but it would be fine to send it to a different router too)
Chandra Sekhar Manginipalli
@leo12chandu
Jun 12 2018 15:24
@nathvi - https://getakka.net/articles/remoting/transports.html - "A"transport" refers to an actual network transport, such as TCP or UDP. By default Akka.Remote uses a DotNetty TCP transport, but you could write your own transport and use that instead of you wish."
Essentially if you need to connect to a UDP transport, you could write a custom extension and use it if there isnt already one. However, if you want to use the existing tcp one. Perhaps one thing I can think of is, the app that you want to communicate in a udp fashion, can receive udp requests and you can make a call to the actorsystem using TCP to the top level actor if that is a possibility?
nathvi
@nathvi
Jun 12 2018 15:30
so basically,
UDP => TCP => Akka Actor
Chandra Sekhar Manginipalli
@leo12chandu
Jun 12 2018 15:30
yup
nathvi
@nathvi
Jun 12 2018 15:30
hummmm
Marc Piechura
@marcpiechura
Jun 12 2018 15:32
@anton-pt maybe a bidirectional flow would work http://getakka.net/articles/streams/workingwithgraphs.html#bidirectional-flows you could send a item backwards once your processing is done and only if you receive the message you load the next item
Anton Tcholakov
@anton-pt
Jun 12 2018 15:35
Interesting idea, yeah, perhaps that would work. Will try it out, thanks!
nathvi
@nathvi
Jun 12 2018 15:37
@leo12chandu , I'm confused, how can akka not support udp, yet still have this issue?
akkadotnet/akka.net#2995
Chandra Sekhar Manginipalli
@leo12chandu
Jun 12 2018 15:38
Sorry, I am not saying Akka.net does not support udp. I am saying if it does not, perhaps one of the alternatives is UDP => TCP
emphasis on "if there isn't already one"
nathvi
@nathvi
Jun 12 2018 15:49
I don't understand why Akka.IO has both TCP and UDP classes, but the Akka Transport only supports TCP
My brain is going to melt Lol
me-slove
@me-slove
Jun 12 2018 15:56
It could be just an artifact of the original port from java. It seems hard to imagine how one would successfully do any sort of remoting or clustering with an unreliable protocol.
nathvi
@nathvi
Jun 12 2018 15:58
maybe @Aaronontheweb , would know :smile:
Chandra Sekhar Manginipalli
@leo12chandu
Jun 12 2018 16:01

@Aaronontheweb - How do I death watch on IActorRef from a class that is not subclassed from ReceiveActor? It just has access to ActorSelection or Client ActorSystem.

Was able to use the ResolveOne on ActorSelection to be able to successfully send messages to the remote actor on a cluster from outside the cluster. But the issue with Deathwatching this is, deathwatch requires Context.Watch() which is only available on a ReceiveActor subclass.

nathvi
@nathvi
Jun 12 2018 16:30
Just coming across fsCheck. Looks pretty sweet
Bartosz Sypytkowski
@Horusiath
Jun 12 2018 18:04

I don't understand why Akka.IO has both TCP and UDP classes, but the Akka Transport only supports TCP

@nathvi Akka.Remote doesn't use Akka.IO... yet ;)

also UDP is often not enough, because a lot of logic components expects data frames to be passed over the network reliably and in correct order, something that UDP cannot provide by itself
nathvi
@nathvi
Jun 12 2018 21:06
@Horusiath , thanks!
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:35
@nathvi glad you liked the article
nathvi
@nathvi
Jun 12 2018 21:39
@Aaronontheweb , I also liked the one on fsTest. Very useful.
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:40
:+1:
I still need to finish the third part of that series
it's been like two years lol
nathvi
@nathvi
Jun 12 2018 21:41
Has using fsTest helped you find bugs quite a bit?
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:41
oh yeah
had a big IOT project I worked on with an Akka.NET user
where we had to test all sorts of conditions
like Device A and Device B depend on Device C
what happens if Device C crashes?
and we had hundreds of scenarios like that
where we had some generic rules about how that should be handled
had to make sure those rules held up under all conditions
FsCheck helped us prove that
where I invest in FsCheck is when I have to make sure that a particular set of features work well across a large combination of inputs / configurations / scenarios
a mathematician might describe that as a "large combinatoric space"
FsCheck is really good at making it feasible for a programmer to attack those types of problems
because manually writing test cases to cover that space isn't economically feasible
I also use it for trying to prove the existence of race conditions too
have a formula I use for that where FsCheck generates larger and larger random arrays of non-zero, non-one integers
and we force whatever the "thing that might have race conditions" is to multiply all of those integers together, concurrently
if the product of the concurrent operation is different from the product of the single threaded operation
nathvi
@nathvi
Jun 12 2018 21:46
niiice
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:46
then I know the multiplication operation has at least one thing occurring that is unsafe
and therefore the code is subject to race conditions
we use multiplication because it has the commutative property going for it
nathvi
@nathvi
Jun 12 2018 21:48
That's a good idea
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:48
therefore the order of operations doesn't matter
nathvi
@nathvi
Jun 12 2018 21:48
right
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:48
in other platforms like Erlang where they use QuickCheck
the OG FsCheck
nathvi
@nathvi
Jun 12 2018 21:48
lol
"OG FsCheck"
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:49
they can do more sophisticated stuff like use a deterministic scheduler, where they can exhaustively run all possible combinations of how those concurrent operations can be scheduled
and find the exact one that exacerbates a race condition
there was a Microsoft Research project called CHESS that could do this for .NET and C++ on Windows
but I think it's been byte-rotted pretty hard
nathvi
@nathvi
Jun 12 2018 21:49
Wasn't Erlang the inspiration for akka and akka dot net?
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:50
yep
Akka was a translation of the Erlang implementation of the actor model onto a general purpose virtual machine
nathvi
@nathvi
Jun 12 2018 21:50
what is "byte-rotted"?
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:50
means the code hasn't been maintained in years
to a point where you can't even get it to compile anymore
nathvi
@nathvi
Jun 12 2018 21:50
:(
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:50
because some of the things it depends on are deprecated or missing
etc
I thought I saw somewhere that someone had done something similar elsewhere in .NET-land though
outside of MSR
don't recall where I saw that
nathvi
@nathvi
Jun 12 2018 21:52
So there's no way to simulate a deterministic scheduler for multithreaded .net apps?
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:52
btw, just published a new post a couple of hours ago: https://petabridge.com/blog/proper-care-of-akkadotnet-clusters/
going to do a few more "Proper Care and Feeding of Akka.NET Clusters" posts this summer
have some others stubbed out

So there's no way to simulate a deterministic scheduler for multithreaded .net apps?

I thought I saw someone was in the early stages of getting one working, but I don't remember clearly :/

nathvi
@nathvi
Jun 12 2018 21:53
That would be super useful for sure.
I'd be surprised if it wasn't msft
I'll give the article a read. Not sure I'll understand it though :o:
Aaron Stannard
@Aaronontheweb
Jun 12 2018 21:55
it'd be good feedback for me if you could tell me if you didn't understand it
can be tough to tell sometimes when you're sitting down and writing one of these how much developers of different shades and stripes will pick up
want to reach as many as possible
nathvi
@nathvi
Jun 12 2018 21:58
" the official Akka.NET documentation" goes to the main page. Not the specific Akka.Cluster docs.
not a big deal, but
nathvi
@nathvi
Jun 12 2018 22:05

I think the TL;DR should be:

"partitions are most often temporary in nature and we should be hesitant to treat unreachable nodes as though they’re permanently offline.”

Aaron Stannard
@Aaronontheweb
Jun 12 2018 22:05
good points
nathvi
@nathvi
Jun 12 2018 22:12
or:
"Partitions are most often temporary in nature due to the out of the box availability and partitioning tolerance implemented in akka clusters"