Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Chris Lovett
    @lovettchris
    @wanton7, The most important information is on actors overview where it says: Async handlers are allowed so that you can call external async systems in your production code, but this has some restrictions. You are not allowed to directly create parallel tasks inside an actor (e.g. by using Task.Run) as that can introduce race conditions (if you need to parallelize a workload, you can simply create more actors). Also, during testing, you should not use Task.Delay or Task.Yield in your event handlers. It is ok to have truly async behavior in production, but at test time the coyote test tool wants to know about, so that it can control, all async behavior of your actor. If it detects some uncontrolled async behavior an error will be reported.
    wanton7
    @wanton7

    @lovettchris what I was thinking that we would write most of our app with Task based concurrency (using Coyote Tasks) and then write our caching system in same process using actors and Coyote Tasks would call into caching actor system in same process. Is this possible?

    Note that you cannot use the above two programming models at the same time in the same process.

    at https://microsoft.github.io/coyote/learn/overview/what-is-coyote
    Makes me think it's not possible to do.

    Akash Lal
    @akashlal
    @wanton7 You can certainly build your application like you suggested. It is fine to use both Coyote Tasks and Coyote Actors in the same process. The process will run just fine and both Tasks and Actors will inter-operate seamlessly. What is not supported is a Coyote test that exercises both. The coyote test tool currently does not expected to see both programming models in the same test case. One option for you is perhaps that you turn off the (Actor-based) caching when testing the Task-based part of your code, and then test the caching layer separately.
    wanton7
    @wanton7
    @akashlal thanks for the info. My idea was to use them as separate systems anyway. Using actor's turn based concurrency makes local & distributed cache invalidation so much simpler.
    @akashlal anyway our team has to think should we go in for message based actor model or do we still stick mostly with Task based one.
    Lane Kelly
    @lanekelly
    Does Coyote support installation as a .NET Core CLI tool? https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools
    I think it would be an improvement in user-friendliness over the current approach listed here: https://microsoft.github.io/coyote/learn/get-started/using-coyote
    Lane Kelly
    @lanekelly
    Got it working as a CLI tool quite easily, although I had to restrict the Coyote project targets to netcoreapp2.2 only.
    1 reply
    wanton7
    @wanton7
    Our app is currently at this early stage and app that has web api endpoints that contain business logic and call into database and we send some SignalR messages to UI. We actually have had some projects in past where message based actor system would have helped greatly. But I'm not sure what kind of benefits would it bring to our current app. Ones I can think of are easier caching because of turn based Actors and it will be easier to split app into microservices. Plus testing bonuses Coyote will bring. Are there other benefits I'm missing?
    Akash Lal
    @akashlal
    @wanton7 Actors are useful when you can divide up your state into the Actors that will own them. Start with one layer of your system and see the testing benefits that Coyote brings to the table. That will be a good start to evaluate further benefits.
    Chris Blackmoor
    @Chobbly_gitlab
    Hi there. I'm looking at evaluating Coyote for an actor-model project that I'm hoping will kick off in the next few months. I know Orleans is already established but having a read through of the documentation there's a lot in Coyote which would be of benefit. One of the requirements though is that the project will need to run on a supported version of .NET Core, so 3.1 or later. Does anyone know if there any plans to update Coyote to .NET Core 3.1 in the near future?
    Akash Lal
    @akashlal

    @Chobbly_gitlab Yes, 3.1 is coming. To quote @pdeligia

    Regarding netcoreapp2.2, we plan to change to a netcoreapp3.1 target (which is LTS, https://dotnet.microsoft.com/download/visual-studio-sdks, 2.2 is now end-of-life)

    Chris Blackmoor
    @Chobbly_gitlab
    @akashlal Thanks for the quick reply, that's really useful to know.
    1 reply
    wanton7
    @wanton7

    @akashlal we will do proof of concept using only Coyote actors. I haven't designed anything before in this event based programming style so getting it right is not so easy.

    We are using MediatR currently so going actor per request is pretty similar in that sense. Like having actors CreateUserActor and EditUserActor. These actors needs to check permissions that is user allowed to create or edit comments and other stuff. So I was wondering is StateMachine actor best for this? I was thinking request would have multiple states like Init, PermissionCheck, StoreToDatabase and Terminate (not sure if terminate needs to be it's own state). If I understood correctly I should do a monitor that would check that these request actors get terminated properly during tests? We need to add caching at some point so that caches N amount of users. So we should probably have UserStoreActor that would be a named actor "UserStore" and that would then handle caching of these users and start worker actors that will access database so it doesn't block. Are there any example projects even in another language that might help me with the design?

    wanton7
    @wanton7
    I looked projects at https://github.com/microsoft/coyote-samples and I didn't find those helped with request based design where we have to do lot of things like checking authorization, validate that request is valid, check permissions, do a call to SQL database and response to caller.
    Akash Lal
    @akashlal

    @wanton7 Try drawing a state machine on paper for your actors. If you can do it, then probably using the same design with StateMachine is a good idea. If you are unable to clearly identify the "States" of the state machine, then use a normal Actor.

    You can consider using Monitors for checking high-level properties of your system, for instance, that the "work gets done" or "request is always completed". The fact that Actors are terminated properly is a more lower level-check, which is also useful. Start with a simple monitor and once you're comfortable with the testing, then write more sophisticated ones.

    @wanton7 I'm unsure of examples like these -- perhaps Orleans is one place to look for more samples.
    wanton7
    @wanton7
    @akashlal Will it be better for testing if we use StateMachine? Example if we are checking permissions and we would only expect something like PermissionCheckedEvent to be send to the request actor.
    Akash Lal
    @akashlal
    @wanton7 Yes, StateMachines hae more built-in assertion, hence more checking when running tests.
    wanton7
    @wanton7
    @akashlal ok then we will use a StateMachine :)
    wanton7
    @wanton7
    @akashlal Is it OK to do CPU bound work inside an actor? I mean actor you create specifically just for that work and don't care if it receives events during that time. There is nothing about this in the docs that I could find.
    Pantazis Deligiannis
    @pdeligia
    @wanton7 yep, thats absolutety fine, you can create an actor (e.g. from some other actor or request) just to do some specific work (and you don’t need to share its actor id with someone else besides its creator, and no one needs to send it further messages) and when it finishes it e.g. writes or returns the result and then halts (or gets reused by its creator). Actors are very generic concurrent computational constructs so all these scenarios are possible :)
    wanton7
    @wanton7
    @pdeligia great!
    Pantazis Deligiannis
    @pdeligia
    @Chobbly_gitlab just to update you that .NET Core 3.1 support is now out in https://www.nuget.org/packages/Microsoft.Coyote/1.0.4
    Chris Lovett
    @lovettchris
    @wanton7 , "CPU bound work inside an actor", absolutely, if this work is instigated by an event then the Actor makes this super easy because other events will just pile up in the inbox until that CPU bound work is finished. No need to worry about multithreading. But you may need to worry about the inbox getting to full, so you'll need some way to gate how many pending events you queue up. Now often times when people have CPU bound work they want to use multiple cores to get the job done, but you probably don't want an Actor doing that, instead create multiple instances of the actor to get multi-core load balancing working that way.
    ANNOUNCEMENT: upcoming Coyote Webinar , April 30th, register now!
    Noel
    @nanderto
    I am trying to run the testing program on my code and I get this exception Error: [CoyoteTester] unhandled exception: System.BadImageFormatException: Could not load file or assembly 'file:///C:\Users\nanderton\source\repos\FirstAspNetCoyote\bin\Debug\netcoreapp3.1\FirstAspNetCoyote.exe' or one of its dependencies. The module was expected to contain an assembly manifest.
    Can anyone point me I the right direction here? thanks
    Chris Lovett
    @lovettchris
    @nanderto, I can reproduce that also. First you'll need coyote 1.0.4 which supports .dotnet core 3.1. You will need to use FirstAspNetCoyote.dll not the .exe, but seems the asp.net build system is even doing something funny with that because I get Failed to get test method '' from assembly 'FirstAspNetCoyote, so I had better luck moving the Coyote stuff out to a new ClassLibrary which you can test separately, then add a reference to that from the FirstAspNetCoyote project.
    Noel
    @nanderto
    ok I have just updated to 1.04
    I will try moving them into a separate class library.
    Noel
    @nanderto
    @lovettchris I have moved all of the Coyote code to a separate library but I still receive the same error you mentioned above Error: Failed to get test method '' from assembly 'FirstAspNetCoyote, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
    Chris Lovett
    @lovettchris
    But you'd be testing your separate library right, not FirstAspNetCoyote, like this: nanderto/FirstAspNetCoyote#3
    Noel
    @nanderto
    @lovettchris thanks again for the help, I did eventually get it to work. I needed to use the dotnet command not the coyote command, so perhaps that points at something wrong with the way my path is set up.
    Timur Fayzrakhmanov
    @tim-fay
    Hello! Coyote library looks really great, so thanks for the team for doing this!
    I have a heavy background of using Microsoft Orleans so when I saw Coyote introductory I immediately start wondering how these libraries correlates to each other.
    The test tooling is really awesome, and I've not seen anything like that on other actor frameworks (Orleans, Akka, Service Fabric Actors).
    From what I saw in documentation materials, Coyote is hosted on a single process, i.e. executable. Is it capable of running on several nodes (different physical/virtual machines), so that Actors can call each other (like several Silos in Orleans combined into a Cluster, or Akka.Net)?
    Maybe there's a document describing this already, I would really appreciate for the link to read.
    Thank you!
    Pantazis Deligiannis
    @pdeligia
    Thanks @tim-fay! You can read some details here: https://microsoft.github.io/coyote/learn/programming-models/actors/why-actors (and some more relevantFAQs here https://microsoft.github.io/coyote/learn/overview/faq). Basically you are right, Coyote provides only an in-memory Actor type and does not provide a distributed runtime (whereas a framework like Orleans provides a Virtual Actor, which is distributed). Saying this, you can certainly distribute Coyote on several nodes (in fact all Azure services in Microsoft that use Coyote in production, do that in a distributed setup). The reason we do not provide a distributed runtime ourselves, is because we want the Coyote library to be very flexible: you can choose to host Coyote Actors (or Tasks) on top of pretty much any distributed framework that you want, and use any communication/storage mechanism you like (e.g. gRPC, HTTP, Azure Service Bus, etc). E.g. one of the teams uses Coyote on top of Azure Service Fabric, and another uses it with Azure Service Bus and CosmosDb on top of Kubernetes. You have to write the host code yourself and plugin the communication mechanism to connect the actors. To give you an idea how to do it, you can see an example using Azure Service Bus here: https://microsoft.github.io/coyote/learn/tutorials/raft-azure
    2 replies
    Lane Kelly
    @lanekelly
    Hello, I am using --graph but the DGML produced doesn't have any Nodes or Links, only Styles.
    Does it require certain annotations in code? I am trying the HelloWorld sample task. For the CoffeeMachine one I do get a graph produced
    Akash Lal
    @akashlal
    @lanekelly IIRC, the DGML feature currently only works with the Actors programming model, not with Tasks.
    Noel
    @nanderto
    Hi, has anyone had the issue that if you build basic unit tests then async-await tests do not show up in test explorer? They are not found if you run from the command line either. I have tried both MStest and Xunit it does not work for either of them. I receive this error but I am complying > UTA007: Method IncrementCountTestAsnc defined in class SecondAspNetCoyote.Pages.Tests.CounterViewModelTests does not have correct signature. Test method marked with the [TestMethod] attribute must be non-static, public, return-type as void and should not take any parameter. Example: public void Test.Class1.Test(). Additionally, if you are using async-await in test method then return-type must be Task. Example: public async Task Test.Class1.Test2()
    Pantazis Deligiannis
    @pdeligia

    Hi @nanderto, if I understand correctly, you are trying to run a MSTest or xunit where the return type is a Microsoft.Coyote.Tasks.Task? This one https://github.com/nanderto/FirstAspNetCoyote/blob/master/SecondAspNetCoyoteTests/Pages/CounterViewModelTests.cs#L27, right? I don't think that is possible as MSTest or xunit does not understand our type (similar to how an async Main method cannot return a Coyote task) and require a regular C# task. We actually need to add this information to our documentation, but to run Coyote test programmatically (from inside a unit test like MSTest or xunit) and not using the CLI tool 'coyote', you need to do something like the following:

            using Microsoft.Coyote.Specifications;
    
            [TestMethod]
            public async System.Threading.Tasks.Task IncrementCountTestAsnc()
            {
                // Create some test configuration, this is just a basic one using 100 test iteration.
                // Each iteration executes the test method from scratch, exploring different interleavings.
                Configuration configuration = Configuration.Create().WithTestingIterations(100);
    
                // Create the Coyote runner programmatically.
                // Assign the configuration and the test method to run.
                TestingEngine engine = TestingEngine.Create(configuration, async () =>
                {
                    var viewmodel = new SecondCoyoteLibrary.Pages.CounterViewModel(runtime);
    
                    viewmodel.CurrentCount = 10;
                    viewmodel.IncrementAmount = 3;
                    await viewmodel.IncrementCount();
                    Specification.Assert(viewmodel.CurrentCount == 13);
                });
    
                // Run the Coyote test.
                engine.Run();
    
                // Check for bugs.
                Console.WriteLine($"Found #{engine.TestReport.NumOfFoundBugs} bugs.");
                if (engine.TestReport.NumOfFoundBugs == 1)
                {
                    Console.WriteLine($"Bug: {engine.TestReport.BugReports.First()}");
                }
            }

    Basically, you create a Coyote TestingEngine and pass to it a test configuration and a lambda (this lambda is using Coyote tasks). You then run it (which runs it like if you were running the Coyote tool from command line) and finally can check the report for bugs.

    @lanekelly IIRC, the DGML feature currently only works with the Actors programming model, not with Tasks.

    @lanekelly @akashlal thats correct, DGML tracing currently only works for actors (+ @lovettchris )

    Noel
    @nanderto

    @pdeligia Thanks for taking a look. Yes I was returning a Coyote task instead of a System.Threading.Tasks task . Interestingly If I change to a System.Threading.Tasks then my code still compiles and runs in the website. This below is the method that is called and it returns a System.Threading.Tasks.Task

    public async Task IncrementCount()
     {
         var request = new RequestEvent<int, int>(IncrementAmount);
         AddActor = runtime.CreateActor(typeof(AddActor), request);
         var response = await request.Completed.Task;
         CurrentCount = CurrentCount + response;
         runtime.SendEvent(AddActor, HaltEvent.Instance);
     }

    This actually works in the website even though the requested.Completed.Task is a coyote task, but it does not work in the unit test.
    The sample you provide also does not work as there is no runtime available to pass into the method. Besides which, I am not looking to replace the how the Coyote test engine works I just want to be able to run unit tests.

    Pantazis Deligiannis
    @pdeligia

    @nanderto sorry my code snippet was incomplete, this is how you pass the runtime:

    TestingEngine engine = TestingEngine.Create(configuration, async runtime =>
    {
       ...
    });

    Btw, my code does not try to replace how the Coyote test engine works, it shows you how to run a Coyote test from inside another unit testing framework (MSTest, Xunit) using the Coyote systematic testing engine :)

    You can think of the Coyote testing engine as its own "unit test runner for Coyote". The TestingEngine will create a special "systematic testing mode" Coyote runtime and pass it to your test via dependency injection. You are not supposed to create your own Coyote runtime during systematic testing (only in production).

    E.g. see how tests are written here: https://github.com/microsoft/coyote-samples/blob/master/HelloWorldActors/Program.cs. Notice that a runtime is passed as input parameter (and not created by the user), when writing a test method using the Microsoft.Coyote.TestingServices.Test attribute (https://github.com/microsoft/coyote-samples/blob/master/HelloWorldActors/Program.cs#L38), but in the Main method you explicitly create a runtime (https://github.com/microsoft/coyote-samples/blob/master/HelloWorldActors/Program.cs#L16) since that is invoked in production.

    However, using the Microsoft.Coyote.TestingServices.Test only works when running tests with our coyote test command line tool (see https://microsoft.github.io/coyote/learn/tools/testing). What I described above does the same thing but allows you to integrate with other unit testing frameworks like MSTest or Xunit.

    Hope this clarifies your question?

    @nanderto if you just want to run a regular unit test, without the systematic testing capability that coyote test gives you, then you can do this:

            [TestMethod]
            public async System.Threading.Tasks.Task IncrementCountTestAsnc()
            {
                ICoyoteRuntime runtime = new CoyoteRuntime();
                var viewmodel = new SecondCoyoteLibrary.Pages.CounterViewModel(runtime);
    
                viewmodel.CurrentCount = 10;
                viewmodel.IncrementAmount = 3;
                await viewmodel.IncrementCount();
                Assert.AreEqual(13, viewmodel.CurrentCount);
            }

    Notice how I changed the signature of the method to return a regular C# task. Thats all you need to run this. System tasks and Coyote tasks can work together in production :) But doing this approach will result in a flaky test as the concurrency is not controlled, whereas the approach that I described in my last post will result in Coyote controlling the concurrency and systematically exploring interleavings to find bugs in your unit test!

    Noel
    @nanderto
    Not sure what happened yesterday, having the test return a System.Threading.Tasks.Task was not working, but after updating some (xunit) extensions and Visual studio, it started working. So that was great, thanks for the help. I also have the Coyote Test runner running as part of the unit tests as well, although it does not return the exception expected, I can at least keep moving forward. Again thanks for the help
    Kapil Khandelwal
    @kapil_k_twitter
    Hi, I was working on implementing a Coyote State Machine (Master) which will be receiving all the events of specific types. This Master State Machine will be responsible for creating & distributing these events to fixed set of Worker State Machines for actual event processing. I have achieved that part. But now I need to implement some sort of priority queue implementation such that each Worker State Machine maintain a priority queue of events & those having higher priority are processed first. I was not sure how can enqueue all pending events of specific type in my priority queue collection while the Worker Machine is still in "Processing" state i.e. working on particular event processing.
    Akash Lal
    @akashlal
    @kapil_k_twitter Great to hear that you're making progress. Coyote Actors currently only have a FIFO queue for inbox. They don't support priority queues at the moment. It seems you are trying to implement your own priority queue inside the actor? It won't be easy because actors are single threaded. You will need some kind of polling. Thinking out loud, what about the following: your actor periodically sends a special message to itself. The actor dequeues all messages and stashes it in its priority queue until it gets this special message. At this point, it sends the special message to itself and then starts processing its priority queue. Once its priority queue is empty, it goes back to dequeing from its inbox. You get "bounded priority queue" in this case, because you won't be fully able to respect priority of messages in the inbox.
    @kapil_k_twitter Perhaps easiest is to extend the Coyote Actor inbox implementation to have priorities. Feel free to open an issue on it. An example use case would also be useful.
    Chris Lovett
    @lovettchris
    To help implement a priority queue you can use the WildCard event handler which can handle all events sent to your actor, your actor can then put them in a priority queue for handling in the right order. The "special message to self" could be a TimerElapsedEvent from StartPeriodicTimer.
    Kapil Khandelwal
    @kapil_k_twitter
    @akashlal @lovettchris Thanks for your response. Will try out your suggestions.