Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Vladimir Ivanov
    @kripergvg
    For example, Coyote doesn't split my lambda and doesn't test the situation when t1 set x to 1 and t2 set x = 2 but y is still 0
    image.png
    Vladimir Ivanov
    @kripergvg
    image.png
    This asserts doesn't detect the situation when x was set and y wasn't but it could happen in real-world scenario
    Akash Lal
    @akashlal
    @kripergvg By default, Coyote will explore interleavings only at Task boundaries (spawn, await, etc.) so its not going to find the assert violation in your example. There are two options. First, in a real scenario, you would ideally have some protection (synchronization) against data races because your accesses to x and y are racy. Use synchronization like Coyote's asynchronous locks or semaphores. Coyote tester will then explore more fine-grained interleavings (at the level of the sychronization operations). The option is more low-level, where you can insert context switch points yourself. For instance, try inserting Task.ExploreContextSwitch between x=1 and y=1 and see what happens.
    Vladimir Ivanov
    @kripergvg
    @akashlal Cool. Thank you for your answer.
    Immad
    @imnaseer
    @kripergvg Like Akash said, Task.ExploreContextSwtich is the way to go if you want Coyote to explore data races around shared variables. In practice, a lot of interesting concurrency issues happen when reading/writing to external resources, say, database access and those accesses often end up spawning new Tasks so checking the interleavings at Task boundaries is fairly effective. Here is a way-too-detailed write-up talking through the natural interleavings of a small .NET code snippet and the subset which Coyote explores: https://github.com/imnaseer/coyote-explainer/blob/master/TaskBasedProgrammingModel.md
    wanton7
    @wanton7
    Two questions
    1. Why is there no timeout support for ReceiveEventAsync?
    2. If I have storage that I want to support multiple messages coming in and I have actor like UserStoreActor. Then that actor delegates messages to other actors that it creates that are only used to receive and handle single message (one for every database request). What is the proper way to create those kind of actors? I mean do I call Halt() at end of its OnEntry method or what?
    2 replies
    wanton7
    @wanton7

    @akashlal it did answer my question and question wasn't properly formed it was about how do you create actor for single task, but issue I created to Coyote repo and answer you added there also answered that with an example. I'm evaluation Coyote for our app company I work for is building. What we have is just normal app with with React UI and API similar to REST. It's going to be multi-tenant app where tenants can register them self. I'm just trying to get my head around how Coyote works and how could we integrate to it to our app.

    I'm still having little bit of trouble understanding how would we write tests all those events we will be sending from our API controllers to actor runtime using Coyote tests. Those event classes might be coming from JSON deserialization. Example we might have CommentCreateEvent that would contain Text property that should not be null, empty or over certain length. Should we use Coyote randoms to init properties like that so they will randomly have any of null, empty, ok (a valid value) or over max length value?

    We would also like to write permission and authorization checking system using actor model. Example if I send GetChannelEvent and it would contain current workspace id, channel id to get and current user Id, how could I have shared authorization code to check If sending GetChannelEvent for that specific channel id is valid for current user? I mean is the a way to somehow forward it to permissions checking actors first? In our current proof of concept app we use MediatR and we do permissions checking in it's pipeline.

    Akash Lal
    @akashlal

    @wanton7 Yes, you can use RandomBoolean or RandomInteger to construct a space of possible input values to drive your test.

    I don't follow you authorization example. Decide first on breaking up the logic of your application into actors (e.g., one actor designated to do permissions-checking), then write the tests as if you are simulating a real workload through the system. In general, a coyote test can exercise multiple actors.

    wanton7
    @wanton7
    @akashlal my explanations are quite bad :) What I wanted to ask that is there a way to route GetChannelEvent through some permission checking actor automatically. If not what would be best way to model that? Example should I send event to channel permissions checker actor and that would then forward event to ChannelManager if check passes or if check fails it would directly send failure event to caller?
    Akash Lal
    @akashlal
    @wanton7 What you are saying sounds good. There is no default support in Coyote for doing this; you'll have to program the logic yourself. It is usual for applications to have a network of actors.
    wanton7
    @wanton7
    @akashlal Thanks good to know that I have do it myself so I can focus on designing how to best do it for our use case.
    Chris Lovett
    @lovettchris
    I could imagine using Monitors for "Checking" that something is authorized. Monitors are good for asserting some global condition is true across all your actors. So the entry point could send current user id to a Monitor, and later code could send authorization messages to the same Monitor which then asserts the user is authorized for that action to be done. The Monitor then acts as an authorization checker...
    Noel
    @nanderto
    Are there any samples for how Coyote can be used in a ASP.Net (or WebApi) application. I cant find any way or receiving a message back from an actor without being an actor. And If my receiving end has to be a Actor the how do I get a reference to the Actor so that I can access the data in it? the only CreateActor() method returns an ActorID.
    wanton7
    @wanton7
    @nanderto check this microsoft/coyote#22
    Chris Lovett
    @lovettchris
    wanton7
    @wanton7
    Is it still true what docs say that you can't mix Task and Actor based Coyote programming models in same process?
    Noel
    @nanderto
    @lovettchris @wanton7 Thanks for the help. I could not get the last line of your code to compile "Return new ActionResult<string>(response);", and I have not used MVC for a while (all Razor Pages) but I did get it to compile and run eventually. Thanks for the help.
    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'