Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
  • 19:50

    Aaronontheweb on dev

    Fix MNTK specs for DData: Durab… (compare)

  • 19:50
    Aaronontheweb closed #4933
  • 19:50
    Aaronontheweb closed #3077
  • 17:58
    Arkatufus commented #4922
  • 17:53
    Arkatufus opened #4933
  • 16:52
    idesai1210 synchronize #204
  • 16:45
    idesai1210 opened #204
  • 16:34
    Arkatufus synchronize #4922
  • 15:01
    Arkatufus synchronize #4924
  • 14:39
    Aaronontheweb commented #4849
  • 14:22
    idesai1210 opened #203
  • 14:18
    Arkatufus labeled #4921
  • 14:18
    Arkatufus unlabeled #4921
  • 13:04
    mrhockeymonkey commented #91
  • 13:02
    mrhockeymonkey opened #91
  • 12:55
    Aaronontheweb synchronize #4926
  • 12:17
    Aaronontheweb commented #4929
  • 07:40
    ismaelhamed commented #4915
  • 04:26
    mchandschuh commented #4915
  • 02:24
    bauersystems closed #4921
Maxim Cherednik
That would be cool.
Boban Pavloski
Hi folks
anyone using akka.net mysql persistence plugin?
Hi Everyone,
I am just getting started with Akka.Net, I want to use it to create micro services, which I'm also just getting started with as well. I've read that one of the best practices with micro services is have them be as isolated as possible. So don't shared anything between the services, such as code or data storage. Akka.net uses classes/messages to communicate, so those class would need to be shared among all the services, which would introduce some form of coupling. I don't see how I can have a fully decoupled set of services using akka.net, unless i'm gonna pass a primitive datatype, such as a string (as json) and then deserialize it to objects in each service. but then I lose all the validation that a class would offer. What are my options to using akka.net to create a loosely coupled micro service architecture system?
Youenn Bouglouan
Hi @NyronW , so if I understand correctly, you want to have several microservices being internally implemented as separate actor systems?
For instance, microservice A having its own ActorSystemA, microservice B having ActorSystemB, and so on?
If this is the case, you are free to use different message types for each internal actor system. The only things that would need to be shared are the messages that transfer data between the microservices themselves.
Carlos Torrecillas
hi guys, is there any "obvious" reason why an actor could terminate a method (or finishes a message processing) when invoking an await Method(); ? I trying to figure that out but so far I had no luck. I call an I/O operation inside a Receive<RequestMessage> and I can't see any log line or anything going on, really weird. It just start processing the next message in the mailbox
I have used both Receive Async and PipeTo and both print when the message starts to be processed but nothing else
`private void Subscribed()
Logger.Debug($"{Self.Path.Name} node is ready");
        Receive<RequestMessage>(e => ProcessRequest(e));

        Receive<ResponseMessage>(p => SendResponseBack(p));

    private void ProcessRequest(RequestMessage requestMessage)
        Logger.Debug($"{Self.Path.Name} started request processing");

                              .ContinueWith(e => new ResponseMessage(e.Result), TaskContinuationOptions.AttachedToParent & TaskContinuationOptions.ExecuteSynchronously)
                              .PipeTo(Self, Context.Sender);

    private void SendResponseBack(ResponseMessage response)
        Context.Sender.Tell(response, Self);

        Logger.Debug($"{Self.Path.Name} finished request processing");
Carlos Torrecillas
that's the code and I'm not entirely sure what am I doing wrong. The Subscribed method gets invoked when the node joins the cluster and I can see that happening. Then the started processing log line is also printed. But immediately after the next message starts. The operation should take 2 seconds so I should expect to see the "finished" at some point but I see nothing. Also there is nothing related to the logging printed by the dependency inside the method which makes me think that the ProcessAsync simply doesn't start
Carlos Torrecillas
found that out. THe actual message content (Data) was null. It's all good now
you can ignore all of the above
Janusz Fijałkowski
Figured out the problem I've had earlier. It seems Hyperion can't deserialize the Exception type. It actually made me realize I don't need to send the entire object just the error message and stack trace. Yay for lighter payloads.
Alex Valuyskiy
@JohnnyTheAwesome Hyperion has limited support for serializing/deserializing exceptions. But the exceptions should have a default public parameterless constructor
And it does not support custom fields/properties inside exceptions
Janusz Fijałkowski
@alexvaluyskiy Exception does indeed have a public parameterless constructor. However it's TargetSite field is of MethodBase type, which in turn has a protected constructor. Guess this might be it, however I didn't dig further once I've realized that jamming the entire Exception object in a message sent over the network isn't really something that I want to do.
Carlos Torrecillas
Do you guys know of any issue when getting asking for the currentTopics? Once I have a publisher joining a cluster I need to send two messages to check that a specific topic is available to publish. I have added a retry mechanism but that doesn't help. I actually need to send two messages to that actor to make this to work
Carlos Torrecillas
by setting the retries to be half a second it works - fyi
Robert Stiff
hi there
i'm working with Cluster Sharding
I have the example working, but in my project, it is not distributing the work on to my other worker node
hmm, do I have to create a cluster sharding region on each worker?
hmm, i did that, now the work that was being done on my command node has moved to my worker node... and it's stopped executing on my command node
is it bad design to add Actor reference in message?
Arjen Smits
@ryzam no
@Youenn-Bouglouan Thanks for your response, I did not want to have any code shared between the micro services, as that shared code will introduced some form of coupling between the services. If I must share the messages that's passed between each actor system/ services, how would I deal with message versioning?
Janusz Fijałkowski
@NyronW I don't know whether it's the right way to do this or not, but in my system I've just put all the actors and messages in one shared library. This way I avoid the problem with incompatible message versions and I can do cool stuff like fan-out deployment since all my actors have access to each other's definitions. My microservies are essentially empty projects with varying hocon configurations, all they do by themselves is instantiating the actor system.
Also, the microservices aren't actually coupled with each other. They just all depend on same library.
@JohnnyTheAwesome Thanks for your feedback, that is a very interesting option to deploy the micro services using akka.net , However I want each service to be fully independent of each other, so that each service can be developed, maintained and deployed independently, potentially by different teams
I was thinking that I could create some sort of messaging protocol similar to a soap envelope (but as json) that includes meta data in the data sent between each service and then each service will implement its own logic to parse the message and use which every property that they need.
Robert Stiff
as long as you have compatible message contracts shared between teams, then remotes should be able to deserialise the messages
you shouldn't need to do that yourself
@uatec you're right ,I may be over thinking it a bit. I will have a standard json that is sent between each service, such as {type:"MyEvent", serviceId: "ActorSystemA",payload: {prop1:0, prop2:"foo"}}. The type and serviceId properties is mainly for audit purpose
Robert Stiff
i don't think you need that at all
just publish your messages as a nuget package
then consume that package in both publisher and consumer
Gregorius Soedharmo
any way you do it, you'll still have to share something between the 2 end points. using a shared library of messages is just a way to do data contract in a strongly typed way
Robert Stiff
but there is no need to wrap them, because akka can transmit them directly
Gregorius Soedharmo
you'll need that with any technology you'll end up using. json, protobuff, avro, .net serialization, its all the same
and in your example, you just proven that yourself, by saying type:"MyEvent" you're already thinking of a shared message library, or you'll end up with different kind of MyEvent class on each end point, which can be bad
Thanks guys, you're absolutely correct, I was creating a solution to a problem that doesn't exist, I will create a shared library to store the message used throughout the entire system and all services will need to reference that package/library. If a message needs to be significantly updated such as change property name or contructor arguments, then each service will need to be updated as well
Gregorius Soedharmo
that would be the easiest and cleanest way
the slightly harder and messier way is to implement protobuf protocol versioning :P
Jay DeBoer
We are working on a system where we need to not drop messages in the mailboxes on restart. Is there a good pattern to drain or persist contents of mailboxes before the actor system shuts down?
Joshua Garnett
What is the latest ETA on 1.3? Got nailed by akkadotnet/akka.net#2763 and was hoping to pull that in.
Juan Lorenzo Hinojosa Hernandez
Hi everyone, I was wondering if there's a way to test an actor that subscribes to a topic through the DistributedPubSub using the TestKit? when I tried I get null from DistributedPubSub.Get(Context.System)
@NyronW I think you gave up too easily there! Loose coupling seems like a good idea; a public interface that hides internal implementation seems like a good idea. Having a shared library used to "store the message used throughout the entire system" seems (depending on how you meant that statement) like a bad idea - like you're building a monolith by another name. Now if you meant that you were only going to publish shared, "interface" classes, then I'm probably okay with that - but then you're obviously limiting your ability to amend those classes for internal-implementation purposes. I would have thought some strategies for dealing with this are already known and would have been proposed already in this conversation. I can see that it's possible to extend a public message class for internal use by wrapping it as a property of an internal-only message class (and I can see how sticking to an immutability paradigm helps with that); I would also have thought that something like Automapper could be useful at a boundary to copy between public-facing and internal message classes (though perhaps that's just a poor man's serialisation mechanism?). Still, I haven't used Akka extensively myself (and I also happen to think that SOAP gets a bum-rap), so your mileage definitely might vary!
Question regarding PipeTo: when no sender is provided, shouldn't PipeTo use current actor as sender instead of NoSender? Based on scala spec "PipeTo must pick up an implicit sender" i think it should, right?