These are chat archives for akkadotnet/akka.net

8th
Aug 2017
ryzam
@ryzam
Aug 08 2017 03:52
is it bad design to add Actor reference in message?
Arjen Smits
@Danthar
Aug 08 2017 06:44
@ryzam no
NyronW
@NyronW
Aug 08 2017 11:58
@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
@JohnnyTheAwesome
Aug 08 2017 12:24
@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.
NyronW
@NyronW
Aug 08 2017 14:40
@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
NyronW
@NyronW
Aug 08 2017 14:53
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
@uatec
Aug 08 2017 15:09
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
NyronW
@NyronW
Aug 08 2017 15:25
@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
@uatec
Aug 08 2017 15:30
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
@Arkatufus
Aug 08 2017 15:43
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
@uatec
Aug 08 2017 15:44
yeah
but there is no need to wrap them, because akka can transmit them directly
Gregorius Soedharmo
@Arkatufus
Aug 08 2017 15:44
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
NyronW
@NyronW
Aug 08 2017 16:59
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
@Arkatufus
Aug 08 2017 17:03
that would be the easiest and cleanest way
the slightly harder and messier way is to implement protobuf protocol versioning :P
Jay DeBoer
@jaydeboer
Aug 08 2017 19:26
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
@joshgarnett
Aug 08 2017 21:25
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
@MindD3v
Aug 08 2017 21:59
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)
mwardm
@mwardm
Aug 08 2017 22:21
@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!
zbynek001
@zbynek001
Aug 08 2017 23:40
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?
Joshua Garnett
@joshgarnett
Aug 08 2017 23:42
C# doesn’t have implicits
At least not in the same way scala does
My guess is using the Java version as a reference would be a closer apples to apples comparison
zbynek001
@zbynek001
Aug 08 2017 23:43
I know, but that means right now the PipeTo behaves differently, and is causing some deadletters because of this
Joshua Garnett
@joshgarnett
Aug 08 2017 23:44
Depends on your perspective, you are typically going to need to be more explicit in C# than Scala.
zbynek001
@zbynek001
Aug 08 2017 23:46
ok, will have to update the sharding again, because it's causing some issues there