So, I've been researching, a message broker serves as a router and or a message translator.
Is there a way that an actor can receive messages from a non actor?
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.
@Aaronontheweb , your article on large messages and Sockets in Akka.NET was very informative.
@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
@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.
@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?
@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?
@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)
@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?
so basically,
UDP => TCP => Akka Actor
yup
hummmm
@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
Interesting idea, yeah, perhaps that would work. Will try it out, thanks!
@leo12chandu , I'm confused, how can akka not support udp, yet still have this issue?
akkadotnet/akka.net#2995
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"
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
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.
maybe @Aaronontheweb , would know :smile:
@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.
Just coming across fsCheck. Looks pretty sweet
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
@Horusiath , thanks!
@nathvi glad you liked the article
@Aaronontheweb , I also liked the one on fsTest. Very useful.
:+1:
I still need to finish the third part of that series
it's been like two years lol
Has using fsTest helped you find bugs quite a bit?
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
niiice
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
That's a good idea
therefore the order of operations doesn't matter
right
in other platforms like Erlang where they use QuickCheck
the OG FsCheck
lol
"OG FsCheck"
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
Wasn't Erlang the inspiration for akka and akka dot net?
yep
Akka was a translation of the Erlang implementation of the actor model onto a general purpose virtual machine
what is "byte-rotted"?
means the code hasn't been maintained in years
to a point where you can't even get it to compile anymore
:(
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
So there's no way to simulate a deterministic scheduler for multithreaded .net apps?
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 :/
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:
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
" the official Akka.NET documentation" goes to the main page. Not the specific Akka.Cluster docs.
Maybe link it to: http://getakka.net/articles/clustering/cluster-overview.html
not a big deal, but
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.”
good points
or:
"Partitions are most often temporary in nature due to the out of the box availability and partitioning tolerance implemented in akka clusters"
"Partitions are most often temporary in nature due to the out of the box availability and partitioning tolerance implemented in akka clusters"