Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 14:21
    Ralf1108 edited #3933
  • 14:17
    Ralf1108 opened #3933
  • 12:57
    Aaronontheweb commented #3904
  • 12:15
    Aaronontheweb synchronize #3927
  • 11:21
    Zetanova synchronize #3916
  • 08:35

    Aaronontheweb on dev

    Fix build script to be able to … (compare)

  • 08:35
    Aaronontheweb closed #3924
  • 08:28
    Aaronontheweb synchronize #3927
  • 08:28
    Aaronontheweb synchronize #3924
  • 08:28

    Aaronontheweb on dev

    added updated Windows Release p… Merge pull request #3869 from A… Fixed Akka.Remote.ResendUnfulfi… and 6 more (compare)

  • 08:28
    Aaronontheweb closed #3932
  • 08:22
    Aaronontheweb opened #3932
  • 08:16

    Aaronontheweb on 1.3.15

    (compare)

  • 08:14

    Aaronontheweb on master

    Fixed Akka.Remote.ResendUnfulfi… added v1.4.0-beta2 release note… added Akka.NET v1.3.15 release … and 2 more (compare)

  • 08:14
    Aaronontheweb closed #3931
  • 08:11
    Aaronontheweb synchronize #3931
  • 07:59
    Aaronontheweb commented #3905
  • 07:58
    Aaronontheweb edited #3931
  • 07:57
    Aaronontheweb commented #3889
  • 07:54
    Aaronontheweb synchronize #3931
Vasily Kirichenko
@vasily-kirichenko
yes, we use Consul discovery on prod, but on a small (~10 nodes) cluster. When I tried to use it on a ~200 nodes cluster, there was an exceptions storm and I rolled back it quickly.
so if I were asked what problem I have with akka, I'd say - consul.
Vasily Kirichenko
@vasily-kirichenko
I am just not confident that the current solution can scale. not good. So I'm gonna try Lighthouse for the new project.
Must Lighthouse nodes be updated when I update akka packages?
Shukhrat Nekbaev
@snekbaev
@marcpiechura @AndreSteenbergen thank you
Vagif Abilov
@object
@vasily-kirichenko AFAIK only when underlying comminication format changes.
AndreSteenbergen
@AndreSteenbergen
dot netty was upgraded recently, 1.3.8 has a newer dotnetty, so I would recommend updating, if you are using 1.3.8 remote someplace, I would recommend upgrading.
Arjen Smits
@Danthar
@vasily-kirichenko lately every update to Akka contains some form of improvements to the cluster system. Which means that updating your lighthouse instances as well, is strongly recommended.
Roger Martinez
@regormz_twitter
Hello everybody!!. I wonder if Akka is able to manage an overflow exception occurred in an actor. It closes the application and it does not execute the supervisor strategy.
Bartosz Sypytkowski
@Horusiath
@vasily-kirichenko would you like to describe this as an issue of github? It's a note worth tracking.
Vagif Abilov
@object
@regormz_twitter newer versions of NET don't allow catching StackOverflowException in a try-catch block. This is something you have to resolve outside Akka.
Shukhrat Nekbaev
@snekbaev
what is the recommended approach to mocking child actors, say, I have actor X which internally creates A and B. I'd like to test only X and would like to substitute A and B with test probes and probably autopilot(?). However, because X does Context.ActorOf it doesn't seem possible, unless, of course, there's way to hook into some Context.ActorOf test callback if one exists. Another approach I've found is to pass a dependency into X which is responsible for creating children and substitute it when testing. Or... maybe just extend the static Props actor creator for X and make it receive a lambda which takes in the Context
Arsene T. Gandote
@Tochemey
Hello
How can I best load test my actors?
Stijn Herreman
@stijnherreman
I'm considering rewriting my unit tests for an FSM because they often unnecessarily break when changing implementation details of the FSM. https://www.planetgeek.ch/2011/05/17/how-to-unit-test-finite-state-machines/ advises against calling a method like SetState in the unit test, and advises testing for side-effects external from the FSM. That certainly sounds like it could reduce test breakage. Anyone here experienced with testing FSMs? What do you recommend?
Bartosz Sypytkowski
@Horusiath
@snekbaev actors can promote a bit different approach to unit testing. Since a single application feature can be result of work of multiple actors, testing them in isolation sometimes just doesn't make sense. Actors work together in systems, and sometimes it's best to test them as such.
@stijnherreman from my experience in any message based system the best way of working is to have a collection of inputs that you wan to test (they also are responsible for moving state machine to a desired state) and then just assert outputs and side effect. In practice internal state and implementation doesn't really matter as long as FSM reacts with world around it as designed.
Bartosz Sypytkowski
@Horusiath
@Tochemey what do you mean by that? There are plenty of ways to perform load tests, but everything starts with what is this test supposed to answer?
Shukhrat Nekbaev
@snekbaev
@Horusiath I've test covered the child actors individually (they don't have their own children), but I'd like to test the orchestration logic for their parent, for example, that it stashes correctly, takes certain actions depending on what children reply. Of course I could leave as is, but in this case will have to mock a lot of things and I don't really feel like I need to do that in this specific case. What I'm trying to do now: I created a nested class for the parent which inherits in interface for creation of Props for A and B. Then I added one more static Props methods in to X for its own creation, one overload takes IChildCreator. Now I'm trying to mock this interface and return a test probe with autopilot and see it this even works :)
Shukhrat Nekbaev
@snekbaev
heh, it seems to work, but will test further. If somebody needs to pass a probe and return Props - a dummy wrapper seems to do the trick (found online):
public sealed class TestProbeWrapper : UntypedActor
        {
            private readonly IActorRef _target;

            public TestProbeWrapper(IActorRef target)
            {
                _target = target ?? throw new ArgumentNullException( nameof( target ) );
            }

            protected override void OnReceive( object message )
            {
                _target.Forward( message );
            }
        }
Props.Create( () => new TestProbeWrapper( getActorProbe ) )
Vasily Kirichenko
@vasily-kirichenko

@Horusiath what is a more typed way to make an Ask?

let loop (ctx: Actor<Msg>) (state: State) = function
    | GetConfiguration ->
         ctx.Sender() <! (Ok state.Configuration : Result<Configuration, string>)
         ignored()

here if I remove the type hint it's inferred as Result<Configuration, obj> which results with disasters.
It's an entry point to the actor system, so I cannot pass an IActorRef<>.

Bartosz Sypytkowski
@Horusiath
@vasily-kirichenko popular option is to use replyTo pattern (add a field to a message, usually called ReplyTo), which contains an actor to which you may want respond to. Then in code instead of sending reply to Sender, send it to msg.ReplyTo. This could work with ask via Ask overload - tbh. I'm not sure if this method is already published.
Jay DeBoer
@jaydeboer
Is it possible to have an actor not restart its children when it encounters an exception and restarts?
lujunjie
@LosCaesar_gitlab
I want to know how to implement some actors to form a ring and make multiple rounds of messaging?Thanks
Vasily Kirichenko
@vasily-kirichenko
@Horusiath I need to "ask" an actor outside actor system (it's a call from Fable.Remoting). I have only IActorRef<'a> on which I can call <?, but it's untyped. You suggest to pass an IActorRef<> to receive response, but where can I get one?
Bartosz Sypytkowski
@Horusiath
@vasily-kirichenko this is what ask overload I give you a link to is all about (instead of message it takes message factory which takes temporary callback address as a param). But it's not exposed directly in Akkling yet
Vasily Kirichenko
@vasily-kirichenko
@Horusiath thanks. We need to add it to Akkling.
Stijn Herreman
@stijnherreman
When actor A sends a message to actor B, and B is supposed to reply to A with some data, how do I inform A of a failure in one of B's children? This cannot be done with a supervisor strategy it seems? The goal is to let A know it should stop its process and shut down, logging a failure somewhere.
Stijn Herreman
@stijnherreman
Maybe I need to clarify a bit. B is a supervisor that Forwards messages to children. Failure in children is escalated to B, so I'm looking for a way to have B Tell A about the failure.
Vasily Kirichenko
@vasily-kirichenko
@stijnherreman You can watch an actor.
Stijn Herreman
@stijnherreman
@vasily-kirichenko Thanks, I'll take a look
Vagif Abilov
@object
I wonder what would be the best way to investigate timeout problems with SqlServer adapter. Recovery of persistent actors in our system sometimes fail with timeout exception. When we traced low-level db activities we found that sometimes INSERT into EventJournal doesn't return for a long time (example: 42 seconds), and it blocks SELECT from the same PersistentId. Such long time on INSERT doesn't make sense, but we are using BatchingJournal. Can this be part of the problem? /cc @Horusiath
Vasily Kirichenko
@vasily-kirichenko
select (nolock)?
Vagif Abilov
@object
We don't do these SELECTs.
It's all Akka EventJournal adapter
this one? :)
Vagif Abilov
@object
Yes. Temporarily switched from Batching to non-batching journal. No difference
Bartosz Sypytkowski
@Horusiath
@object you can relax isolation level of your transactions using isolation-level config
there are also max-batch-size, max-buffer-size and max-concurrent-operations
Bartosz Sypytkowski
@Horusiath
it works like that: batching journal buffers incoming write requests (the max size of that buffer is max-buffer-size=500000, after that size is reached any more writes will be denied until buffer will be freed). These writes are picked into batches (up to max-batch-size=100) and every batch is essentially a single db request - keep in mind that if you store mutliple events in a single Persist request, they all count as 1 atomic write.
last, since db requests are asynchronous by default, we don't call them one by one. Instead we execute many of them up to a given concurrency limit (max-concurrent-operations=64). keep in mind, that every operation uses separate db connection - ADO.NET is pooling them and afaik pool size is 100 by default.
Bartosz Sypytkowski
@Horusiath
also max concurrency limit is specific to batching journal, not shared with snapshot store, but they still use the same ADO.NET pool given the same connection string. So they can compete for connections in the pool. If you want a separate pool for snapshot store you can specify a different connection string for it - if I remember correctly ADO.NET allocates connection pools based on connection string matching
Vasily Kirichenko
@vasily-kirichenko
@Horusiath It seems you don't use bulk insert, why?
Vagif Abilov
@object
Tried different isolation levels, no difference.
Bartosz Sypytkowski
@Horusiath
@vasily-kirichenko I wanted to, just haven't got time to implement it. Current implementation was more inline with the one, that already existed before, so I wanted to be sure that it could work as drop-in replacement without breaking things. Tbh, if akka.persistence was implemented on top of streams, batching journal and normal one would probably differ only with the stage in between performing the batch operation.