Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:58
    Arkatufus opened #4226
  • 06:53

    dependabot-preview[bot] on nuget

    (compare)

  • 06:53
    dependabot-preview[bot] closed #4187
  • 06:53
    dependabot-preview[bot] commented #4187
  • 06:53
    dependabot-preview[bot] labeled #4225
  • 06:53
    dependabot-preview[bot] opened #4225
  • 06:53

    dependabot-preview[bot] on nuget

    Bump Google.Protobuf from 3.11.… (compare)

  • 06:52
    dependabot-preview[bot] labeled #4224
  • 06:52
    dependabot-preview[bot] opened #4224
  • 06:52

    dependabot-preview[bot] on nuget

    Bump FsPickler from 5.3.0 to 5.… (compare)

  • 06:44
    dependabot-preview[bot] labeled #114
  • 06:44
    dependabot-preview[bot] opened #114
  • 06:44

    dependabot-preview[bot] on nuget

    Bump MongoDB.Driver from 2.10.1… (compare)

  • Feb 16 10:34
    cptjazz opened #4223
  • Feb 15 11:28
    blackclavus commented #4218
  • Feb 14 20:59
    Aaronontheweb commented #4143
  • Feb 14 20:58
    Aaronontheweb closed #4143
  • Feb 14 20:51
    Aaronontheweb synchronize #4211
  • Feb 14 20:42
    Aaronontheweb milestoned #4169
  • Feb 14 20:42
    Aaronontheweb milestoned #4146
Shukhrat Nekbaev
@snekbaev
if I have actor A and it inside does ActorSelection for actor B to send messages, how do I setup the hierarchy for B for testing?
I understand the don't use ActorSelection and pass IActorRef via constructor, but those two hierarchies are quite different and I will have to carry required IActorRefs everywhere and finally pass to the ctor of A, that's a bit of a...
Ismael Hamed
@ismaelhamed
@Horusiath also lack of inheritance? Though I guess you could argue that you don't need/want it in your messages anyway. Thanks, man.
Shukhrat Nekbaev
@snekbaev
@ismaelhamed I used inheritance in some messages, for example for RequestGet which implementation was identical for several target actors. Thus I created an abstract RequestGetBase class. Messages are routed through a parent gateway actor, but children deal with RequestGetBase. Children also have a base class which actually handle that kind of message
Shukhrat Nekbaev
@snekbaev
it seems ActorOfAsTestActorRef is for setting up the hierarchy, however, with ActorSelection, I think I'm running into race condition :)
Shukhrat Nekbaev
@snekbaev
@Horusiath I'm working on my first akka.net test, say, I have a hierarchy and there's an actor on a third depth level that is required (let's call it Target). In the test I'm creating the root actor for that hierarchy using Sys.ActorOf. After that I'm creating an actor ("Source") who is going to send and receive the message from the "Target". Internally "Source" does ActorSelection into "Target". It seems that when I run the test, the "Source" performs the ActorSelection into the actor which doesn't exist yet, thus, message is lost. The way I fixed the test for now is by adding the Task.Delay(1000); before creating the "Source" actor. If there a way to await until "Target" with its entire parent hierarchy is created first?
Shukhrat Nekbaev
@snekbaev
hm, in the aforementioned scenario I changed the variable that holds "Target" IActorRef to be a public static one. Then in the "Source" instead of ActorSelection I used that variable directly via its container type. Was expecting it to contain a value, but it turns out to be null. When I have 1 second delay between actor "Target"'s parent hierarchy and "Source" actor creation, then there's a value, in other words, issue is not about using ActorSelection, but rather race condition for creation of actors. "Source" is being created and sends messages before "Target"'s parent hierarchy is initialized, though in the code I have Sys.ActorOf for "Target" before the "Source"
Bartosz Sypytkowski
@Horusiath
@snekbaev I don't really know what you want to hear here. There are several ways of establishing contact between two actors. From stuff like preinitialization of actors, via publish/subscribe buses to custom actor system extensions.
what's useful in case depends, on what do you actually try to do (since this is not that obvious, as you don't describe what you want to do, only how are you trying to do it)
Shukhrat Nekbaev
@snekbaev
@Horusiath could you please elaborate the "custom actor system extensions". As for what am I trying to do:
imagine two hierarchies, so basically I need to send the message from some level of the second hierarchy to some level of the first hierarchy. As recommendation was to use IActorRef I felt like it will be a bit too much to drag along the required IActorRefs from the first hierarchy into the second via the constructor (so that it will be passed along to the children). That's why I used ActorSelection. Yesterday I ran into the race condition of actor creation: my test actor was created and sent the message before the first hierarchy was created, thus added the artificial delay to the test (hack?) which helped. After looking at that and not really liking the solution I decided to refactor and actually carry the first hierachy IActorRef into the second one via constructors: parent -> child -> child that will use that IActorRef. However, because there are several IActorRefs needs I decided to actually take only their parent IActorRef and pass only it. Inside that parent I receive all the messages and forward to the corresponding child. I decided not to list all possible child messages in the OnReceive's switch, but rather just check against interface. I.e. every child actor's message implements actor specific ISomeActorMessage interface. This way I don't have to clutter the parent's OnReceive. Not sure yet if that's the best practice, it does make the parent smaller, though need to be careful to implement the correct interface for the correct child actor messages.
Bartosz Sypytkowski
@Horusiath
@snekbaev your later design sounds good. So what's the problem?
Shukhrat Nekbaev
@snekbaev
@Horusiath was concerned whether I went too far :) also that I have to carry an actor ref from one hierarchy into sub levels of another, i.e. parent actors are just a pass-through for the reference in that case
Havret
@Havret
Tip of the day: if you save your hocon configuration as *.conf you will get nice systax coloring in Visual Studio. :D
Havret
@Havret
image.png
Peter Shrosbree
@pshrosbree
I see TypedActor is marked as obsolete in Akka 1.3.8. What is the replacement?
image.png
Oh, ignore me. Long day...
:)
Ismael Hamed
@ismaelhamed
@Havret eeeuuuu!
Shukhrat Nekbaev
@snekbaev
say I have some actor X, it receives the message "Msg", does some processing and replies. When it receives it, it puts it into internal dictionary for the correlation purposes, then asks some other actors, collects the information and before replying removes the entry from the dictionary. I'd like to test that during each internal step dictionary is being correctly updated. What would be the proper approach to test this?
Marc Piechura
@marcpiechura
@snekbaev That the actor stores messages in a dictionary should be an implementation detail and as such shouldn’t be tested explicitly, try to find a test case that tests the logic behind it, e.g. if the actor receives the same message twice before the first has been processed, the second one should be ignored or the actor should respond with a special message.
AndreSteenbergen
@AndreSteenbergen
@snekbaev try reading up on Behaviour Driven Development. Your actors are "black boxes" behaving is some manor. You could approach actor testing a lot like BDD, given a set of already processed events, when command x is raised, then you will expect some outcome. Main focus is actors behave like you need on the outside.
Vagif Abilov
@object
I have a question about Petabridge.Cmd. Currently it runs in a Powershell console. Are there plans to expose its functionality as an API so it can be integrated in customised cluster monitoring tools? /cc @Aaronontheweb
Vasily Kirichenko
@vasily-kirichenko
Vasily Kirichenko
@vasily-kirichenko
Is Lighthouse mandatory to be used? What if I just deploy 5 nodes, 2 of which are seeds?
AndreSteenbergen
@AndreSteenbergen
No not mandatory, it's just so you have two well known nodes you can always and easily find
I guess that's where the comes from as well
Check the code, it is a cluster node, without any functional parts, except hosting an akkasystem.
Vasily Kirichenko
@vasily-kirichenko
ok, thanks
Vagif Abilov
@object
@vasily-kirichenko It's not mandatory but we found it convenient for CI process - we always have our Lighthouses running, no need to redeploy them. And other components are updated all the time.
But didn't you experiment with Consul? You can even replace LH with your own discovery tools.
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
@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 );
            }
        }