Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 11 23:52
    scptre commented #4082
  • Dec 11 14:26
    nagytech commented #3954
  • Dec 11 11:18
    nagytech edited #4089
  • Dec 11 11:17
    nagytech opened #4089
  • Dec 11 11:00
    nagytech commented #4083
  • Dec 11 08:34
    jiyeongj commented #4083
  • Dec 11 08:33
    jiyeongj commented #4083
  • Dec 11 08:33
    jiyeongj commented #4083
  • Dec 11 07:57

    dependabot-preview[bot] on nuget

    (compare)

  • Dec 11 07:57

    dependabot-preview[bot] on dev

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • Dec 11 07:57
    dependabot-preview[bot] closed #104
  • Dec 11 07:52
    dependabot-preview[bot] synchronize #104
  • Dec 11 07:52

    dependabot-preview[bot] on nuget

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • Dec 11 07:52
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    Aaronontheweb commented #104
  • Dec 11 07:43

    dependabot-preview[bot] on nuget

    (compare)

  • Dec 11 07:43

    dependabot-preview[bot] on dev

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • Dec 11 07:43
    dependabot-preview[bot] closed #102
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
Janusz Fijałkowski
@JohnnyTheAwesome
@uatec Quoting the docs: "You can communicate with cluster singleton actors by using ClusterSingletonProxy. It will automatically keep track of the actor's current location, update it if necessary and buffer all messages during the handover process." So finding it shouldn't be a problem. I haven't used this feature yet tho, so I might be missing something.
Robert Stiff
@uatec
oh cool, that sounds exactly what i want
now, if only I could convince it to actually start
Robert Stiff
@uatec
it's starting the singleton manager, but not my singleton
Robert Stiff
@uatec
wah? my lighthouse keeps shutting itself down
zbynek001
@zbynek001
Any idea why Serialization.SerializedActorPath sometimes returns path without address? This then messes up comparing actor references. E.g. in sharding i've events ShardHomeAllocated with full address of region but then I have ShardRegionTerminated with just local address of region. And the PersistentShardCoordinator state get's corrupted by this, because they are not equals
Robert Stiff
@uatec
hmm
i'm using Castle DI, and when a remote actor starts on that node, Akka.net invokes a random windsor dependency resolver, without a system attached :|