Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 05 17:21
    Aaronontheweb synchronize #4079
  • Dec 05 17:20
    Aaronontheweb labeled #4084
  • Dec 05 17:20
    Aaronontheweb labeled #4084
  • Dec 05 17:20
    Aaronontheweb milestoned #4084
  • Dec 05 17:20

    Aaronontheweb on dev

    Remove string interpolation fro… (compare)

  • Dec 05 17:20
    Aaronontheweb closed #4084
  • Dec 05 17:20
    Aaronontheweb commented #4084
  • Dec 05 15:43
    ismaelhamed opened #4084
  • Dec 04 23:34

    Aaronontheweb on dev

    Made cleanup call thread-safe (… (compare)

  • Dec 04 23:34
    Aaronontheweb closed #4081
  • Dec 04 23:34
    Aaronontheweb closed #4020
  • Dec 04 19:08
    Aaronontheweb commented #4079
  • Dec 04 18:35
    maratoss review_requested #4079
  • Dec 04 18:26
    maratoss synchronize #4079
  • Dec 04 07:42
    jiyeongj edited #4083
  • Dec 04 06:45
    jiyeongj opened #4083
  • Dec 04 06:35
    dependabot-preview[bot] labeled #130
  • Dec 04 06:35
    dependabot-preview[bot] opened #130
  • Dec 04 06:35

    dependabot-preview[bot] on nuget

    Bump System.Data.SqlClient from… (compare)

  • Dec 03 19:10
    Aaronontheweb synchronize #4081
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
Library* at the same time.
Youenn Bouglouan
@Youenn-Bouglouan
Last remark ☺you mentioned a message example that looks like this: {type:"MyEvent", serviceId: "ActorSystemA",payload: {prop1:0, prop2:"foo"}}.
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.
Janusz Fijałkowski
@JohnnyTheAwesome
While using CoordinatedShutdown with exit-clr = on I get a failed association error thrown in Lighthouse, it appears after the "Leader is removing confirmed Exiting node" message. Is this supposed to happen? Is there a cleaner way to shut down the remote before closing the application?
Robert Stiff
@uatec
i'll give it a go
so once it's started, the only way to stop it would be to kill the entire cluster, or find it and terminate the cluster singleton thingy