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

ryzam

@ryzam

is it bad design to add Actor reference in message?

Arjen Smits

@Danthar

@ryzam no

NyronW

@NyronW

@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

@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

@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

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

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

@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

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

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

yeah

but there is no need to wrap them, because akka can transmit them directly

Gregorius Soedharmo

@Arkatufus

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

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

that would be the easiest and cleanest way

the slightly harder and messier way is to implement protobuf protocol versioning :P

Jay DeBoer

@jaydeboer

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

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

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

@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

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

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

I know, but that means right now the PipeTo behaves differently, and is causing some deadletters because of this

Joshua Garnett

@joshgarnett

Depends on your perspective, you are typically going to need to be more explicit in C# than Scala.

zbynek001

@zbynek001

ok, will have to update the sharding again, because it's causing some issues there

NyronW

@NyronW

@mwardm I think that the only way I can have a fully decouple set of services is to use a json string. WHat I meant by shared library to store the messages used throughout the system is that the class library would contain the message/class that used to pass data between each micro service. e.g. ProcessPayment(string customer, Guid OrderId, double Amount). All the micro services would need to add reference to that shared library, thus creating source code coupling between the services as they all depend on that library

Joshua Garnett

@joshgarnett

@NyronW definitely take a look at protobuf for your shared messages. It’s the direction the Scala/Java project has gone in. Then you can just share the protobuf schema and not worry as much about sharing the c# code.

NyronW

@NyronW

@joshgarnett I am not very familiar with protobuf schema, how they enable to accomplish my goal of a fully decouple set of micro services?

Vagif Abilov

@object

Looks like we hit a major bug in Hyperion when it comes to JObject serialization: akkadotnet/Hyperion#66

Youenn Bouglouan

@Youenn-Bouglouan

Hi @NyronW, a few remarks on what I read so far. First, I'm not really convinced that having a single common library shared be every microservice is the way to go. It's very unlikely that each microservice will have to talk to all the remaining ones. Why not create a common library by topic instead ?

Second, if you do semantic versioning (major minor build...) then you do not need to redeploy everything each time you change something in the shared library. If the changes are only additive, then

You can have microservices using 2 different versions of the same livrrat

Doing so, you're making the messages dependent on the implementation of the microservices. What if you want to drop actors altogether in the next version? You'd have to redefine all your messages. IMO your messages should be implementation-agnostic. Only the microservice that receives a message should decide what to do with the data in it.

Robert Stiff

@uatec

A question about pooling. If an actor creates a pool, but then that parent actor dies... what happens to the pool?

can I find the pool again somehow when the parent actor comes back up? or will the pool children die too and then need to be recreated?

Arjen Smits

@Danthar

@uatec when the parent actor stops. So will all its children

Robert Stiff

@uatec

okay, then that's... manageable

so if i start my parent on Node1, but then that node crashes, Is it possible to make sure that it comes back again on another node?

Janusz Fijałkowski

@JohnnyTheAwesome

@uatec You could try to use Cluster Singleton. I think it's supposed to migrate to a new node when current one crashes.