Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:41
    Aaronontheweb commented #4097
  • 08:19
    ismaelhamed synchronize #4097
  • 02:22
    kimbyungeun opened #4098
  • Dec 15 19:47

    Aaronontheweb on dev

    TypeExtensions.TypeQualifiedNam… (compare)

  • Dec 15 19:47
    Aaronontheweb closed #4071
  • Dec 15 19:47
    Aaronontheweb closed #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb milestoned #3767
  • Dec 15 19:44
    Aaronontheweb labeled #4097
  • Dec 15 19:44
    Aaronontheweb milestoned #4097
  • Dec 15 13:23
    Aaronontheweb commented #4096
  • Dec 15 13:22
    Aaronontheweb commented #4093
  • Dec 15 13:16
    ismaelhamed commented #4093
  • Dec 15 13:04
    ismaelhamed edited #4097
  • Dec 15 13:04
    ismaelhamed opened #4097
  • Dec 15 12:50
    ismaelhamed commented #4096
  • Dec 15 12:48
    ismaelhamed commented #4096
  • Dec 15 12:05
    Aaronontheweb commented #4096
  • Dec 15 11:43
    ismaelhamed commented #4096
Janusz Fijałkowski
@JohnnyTheAwesome
@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
@CarlosTorrecillas
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
@CarlosTorrecillas
by setting the retries to be half a second it works - fyi
Robert Stiff
@uatec
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
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
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.