Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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.
    Lane Kelly
    @lanekelly

    This command doesn't seem to work out of the box: dotnet tool install --global Microsoft.Coyote.CLI

    The error is that the package cannot be found. Is there a prereq I'm missing?

    2 replies
    Pantazis Deligiannis
    @pdeligia
    Hi @lanekelly, there is some issue with publishing the new signed Microsoft.Coyote.CLI package on NuGet that is used to install coyote as a dotnet tool, we are trying to resolve it with the nuget team so hopefully it will not be long until we can publish it, and then you will be able to update it (just realized that we pushed the above command in the docs without the package, sorry for the confusion)
    Lane Kelly
    @lanekelly
    Gotcha, thanks
    Lane Kelly
    @lanekelly
    One issue I'm running into with using Coyote with asynchronous tasks is that I'm not able to use types like ConcurrentDictionary or System.Threading.Channels.Channel since they only expose System.Threading.Tasks.Task/ValueTask. I was hoping to use these sorts of primitives to mock things like service bus queues, but it seems I will have to reimplement them myself to work with the Coyote task type. Any advice on how to proceed from here?
    Akash Lal
    @akashlal
    @lanekelly There shouldn't be any issues with using ConcurrentDictionary. I don't see any of its methods returning a native Task. For improved test coverage, make sure to insert a ExploreContextSwitch before calling any method on a ConcurrentDictionary. Let me look up the Channel type, haven't used it before ...
    Lane Kelly
    @lanekelly
    @akashlal, you're right, I should have specified only Channel as the one with an issue. I suppose I could use BlockingCollection instead with an async wrapper to mock a queue
    Akash Lal
    @akashlal
    @lanekelly I think a bit of work would be required to mock Channel. Ideally, you should mock it in the same way that we mocked TaskCompletionSource. But this implementation uses some internal APIs that make the mocking easy. We are going to consider making these APIs public so that your exercise will be simpler. For now, maybe you can have a simple mock.
    Lane Kelly
    @lanekelly
    @akashlal , thanks. I was just using Channel as a potential way to mock a queue, it's not something I want to mock myself. I ended up using ConcurrentQueue with some async wrapper methods, which is working well
    wanton7
    @wanton7
    Does Coyote support virtual actors similar to Orleans & Dapr? Or is something like UsersActor with specific name the way to go that handles multiple users state? Maybe even using consistent hashing for user id and create UsersActor per cpu core if performance is needed.
    Akash Lal
    @akashlal
    @wanton7 Coyote actors are not virtual. Because they are in-memory, there is no concept of activating/deactivating or moving actors. If you want such functionality, you will have to implement it yourself. I'm not sure what you mean by "UsersActor". What is that?
    wanton7
    @wanton7
    @akashlal having virtual actors doesn't mean they are moved anywhere. You can have virtual actors just in single machine. "UsersActor" would be just actor that keeps and handles state for multiple users. This the way I've done it when I've been using Elixir. It's actor that coordinates state (cache) management for multiple users. In Orleans we have had UserGrain presenter single user and it's state (cache).
    1 reply
    Akash Lal
    @akashlal
    @wanton7 Ok, so you can use a string to create ActorId via ActorRuntime.CreateActorIdFromName and then send messages to that actor. But you still need to create an Actor before you can Send to it.
    Noel
    @nanderto
    I am trying to use the replay command to debug and find the bug, but I don't see from the instructions where visual studio is supposed to find the source code from. The IDE opens up it appears to be in the middle of debugging but there is no where to point it to the source code.
    Chris Lovett
    @lovettchris
    Right, if it has trouble finding the symbols for your code (the code being tested) then the way I normally do it is to load my solution (containing the code being tested) and change the "Executable" to coyote.exe and the command line to be the replay command line then press F5 and then you can watch the entire test sequence take place that leads up to the bug.
    Akash Lal
    @akashlal
    @nanderto What I do is that I add a System.Diagnostics.Debugger.Launch() to the beginning of my test (and recompile). Then when I do replay, I get a window asking me to attach the test to a debugger. I choose the VS instance that has my test code open and I'm good to go.
    Pantazis Deligiannis
    @pdeligia

    Btw, just to add to this, if you run the test from the command line tool (coyote test or coyote replay) you can add the option --break (-b) which will start the debugger before it runs the test (it basically instruments a System.Diagnostics.Debugger.Launch()). This typically opens a Visual Studio selector for the debug session, as @akashlal described. But I have only tried this approach of debugging using the VS IDE on Windows so far.

    Another way, is to run the Coyote test programmatically. We plan to add documentation on this asap, but basically you can programmatically create a Coyote TestingEngine and run the test based on a test Configuration (the coyote command line tool uses this logic under the hood). That way, you can just debug the test with whatever IDE or process you are using until now (e.g. add breakpoints, right click the test and click debug). This is also useful if you want to run Coyote tests on a unit testing framework like xUnit or MSTest, etc. Until we add this info in our docs, you can see my answer on this closed GitHub issue that provides a code snippet how to do this (shows both test and replay): microsoft/coyote#23

    Tomáš Deml
    @tomasdeml
    Hi, I am evaluating Coyote and in the documentation there is no word about the ValueTasktype. I searched the repo and could not find anything related...
    Pantazis Deligiannis
    @pdeligia
    Hi @tomasdeml, thanks for your interest in Coyote! Yes, you are right: we do not support the ValueTask type yet, only the original Task type and other common types like TaskCompletionSource (please note that comparing to our actor/state-machine programming model, our task programming model is still in-preview, so we are keep adding new features and supported types, to make it easier to be consumed, and are prioritizing those based on user demand and feedback). Saying this, supporting ValueTask should not be too hard (as a lot of the logic to control and systematically test those is the same with Task), so we can try to add this asap.
    Rob Landers
    @withinboredom
    Hello all. I was exploring the documentation, but is there a "right" way to serialize/store actors (for program shutdown or resume)?