Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 13 14:40
    cptjazz synchronize #3974
  • Oct 13 14:07
    cptjazz opened #3974
  • Oct 13 08:30
    ismaelhamed commented #3937
  • Oct 12 15:50
    IrvinDominin opened #127
  • Oct 11 18:21
    Aaronontheweb commented #3973
  • Oct 11 18:20
    Aaronontheweb commented #3937
  • Oct 11 18:16
    Zetanova commented #3937
  • Oct 11 18:11
    Zetanova commented #3937
  • Oct 11 15:09
    Aaronontheweb commented #3937
  • Oct 11 15:08
    Aaronontheweb commented #3937
  • Oct 11 14:36
    Aaronontheweb commented #3973
  • Oct 11 01:00
    Horusiath commented #3057
  • Oct 10 20:02
    IgorFedchenko synchronize #3973
  • Oct 10 19:59
    IgorFedchenko synchronize #3973
  • Oct 10 19:58
    IgorFedchenko commented #3973
  • Oct 10 19:53
    IgorFedchenko opened #3973
  • Oct 10 14:04
    stijnherreman commented #3057
  • Oct 10 13:54
    Aaronontheweb commented #3970
  • Oct 10 13:54
    Aaronontheweb synchronize #3970
  • Oct 10 10:10
    Zetanova commented #3937
Vagif Abilov
@object
Thanks for the reference to batching.
Bartosz Sypytkowski
@Horusiath
if you're building from source, you may as well try to build batching journal ;) It has some extra configuration options, but in terms of persistence format it's drop-in replacement of existing journal (also if you need base class for batching journal, it's here: https://github.com/akkadotnet/akka.net/blob/cd33195b5aad34895f0fb69893bd2074d539201f/src/contrib/persistence/Akka.Persistence.Sql.Common/Journal/BatchingSqlJournal.cs )
sorry for that delay, we should push v1.3 already.
Vagif Abilov
@object
But will batching journal be a part of 1.3?
Bartosz Sypytkowski
@Horusiath
it already is, but we need sqlserver impl of it as well + it's opt in, not the default
Vagif Abilov
@object
I was offline for some hours. @Horusiath since you mentioned ADO.NET pool of connections, is it so that our problems may have been caused by exausted connection pool? Especially now that we have refactored large parts of our system (getting rid of consistent hashing btw :-)) and now there are more parallel activities using persistent actors?
So this is something that batching journal can help with, but there's no SQL Server plugin for it right?
Kosta Petan
@kostapetan
btw guys, managed to get the docker-compose setup to work, which looks something like this [API] -> [SEED WORKER] -> [NODE WORKER], I'll try to document it, someone might find it useful
Maxim Cherednik
@maxcherednik
That would be cool.
Boban
@bobanco
Hi folks
anyone using akka.net mysql persistence plugin?
NyronW
@NyronW
Hi Everyone,
NyronW
@NyronW
I am just getting started with Akka.Net, I want to use it to create micro services, which I'm also just getting started with as well. I've read that one of the best practices with micro services is have them be as isolated as possible. So don't shared anything between the services, such as code or data storage. Akka.net uses classes/messages to communicate, so those class would need to be shared among all the services, which would introduce some form of coupling. I don't see how I can have a fully decoupled set of services using akka.net, unless i'm gonna pass a primitive datatype, such as a string (as json) and then deserialize it to objects in each service. but then I lose all the validation that a class would offer. What are my options to using akka.net to create a loosely coupled micro service architecture system?
Youenn Bouglouan
@Youenn-Bouglouan
Hi @NyronW , so if I understand correctly, you want to have several microservices being internally implemented as separate actor systems?
For instance, microservice A having its own ActorSystemA, microservice B having ActorSystemB, and so on?
If this is the case, you are free to use different message types for each internal actor system. The only things that would need to be shared are the messages that transfer data between the microservices themselves.
Carlos Torrecillas
@CarlosTorrecillas
hi guys, is there any "obvious" reason why an actor could terminate a method (or finishes a message processing) when invoking an await Method(); ? I trying to figure that out but so far I had no luck. I call an I/O operation inside a Receive<RequestMessage> and I can't see any log line or anything going on, really weird. It just start processing the next message in the mailbox
I have used both Receive Async and PipeTo and both print when the message starts to be processed but nothing else
`private void Subscribed()
{
Logger.Debug($"{Self.Path.Name} node is ready");
        Receive<RequestMessage>(e => ProcessRequest(e));

        Receive<ResponseMessage>(p => SendResponseBack(p));
    }

    private void ProcessRequest(RequestMessage requestMessage)
    {
        Logger.Debug($"{Self.Path.Name} started request processing");

        _aDependency.ProcessAsync(requestMessage.Data)
                              .ContinueWith(e => new ResponseMessage(e.Result), TaskContinuationOptions.AttachedToParent & TaskContinuationOptions.ExecuteSynchronously)
                              .PipeTo(Self, Context.Sender);
    }

    private void SendResponseBack(ResponseMessage response)
    {
        Context.Sender.Tell(response, Self);

        Logger.Debug($"{Self.Path.Name} finished request processing");
    }`
Carlos Torrecillas
@CarlosTorrecillas
that's the code and I'm not entirely sure what am I doing wrong. The Subscribed method gets invoked when the node joins the cluster and I can see that happening. Then the started processing log line is also printed. But immediately after the next message starts. The operation should take 2 seconds so I should expect to see the "finished" at some point but I see nothing. Also there is nothing related to the logging printed by the dependency inside the method which makes me think that the ProcessAsync simply doesn't start
Carlos Torrecillas
@CarlosTorrecillas
found that out. THe actual message content (Data) was null. It's all good now
you can ignore all of the above
Janusz Fijałkowski
@JohnnyTheAwesome
Figured out the problem I've had earlier. It seems Hyperion can't deserialize the Exception type. It actually made me realize I don't need to send the entire object just the error message and stack trace. Yay for lighter payloads.
Alex Valuyskiy
@alexvaluyskiy
@JohnnyTheAwesome Hyperion has limited support for serializing/deserializing exceptions. But the exceptions should have a default public parameterless constructor
And it does not support custom fields/properties inside exceptions
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