4 ms·

Hi, blog author here. > I'd love to see numbers This was an experiment, and I didn't do a performance test. The Orleans people will tell you that the current

Hi, blog author here. > I'd love to see numbers This was an experiment, and I didn't do a performance test. The Orleans people will tell you that the current production version will process something on the order of a couple hundred thousand of messages per server per second. If your actors are modelled well, this scales to hundreds of servers, so it would be possible to have on the order of tens of millions of messages per second between actors, including persistence. I expect the upcoming Dotnet Core version to do even better. > How's the testing/debugging experience I normally test with xunit, standard dotnet stuff that works very well. Orleans provides a TestingHost that lets you spin up silos for testing grain code in a 'real' environment. This costs some time for startup. The time travel idea needs some devtools ui, which I didn't build. I'm sure this would be possible though, with the limitation that the "edit and continue" feature of dotnet is not as capable as in javascript: often visual studio will tell you that your change requires a full application restart. You can change code and data while paused in the debugger. > What happens when the machine goes down? Orleans would respawn the Grain on another server (using the last-known state) and retry the operation up to two times by default. If you follow a safe implementation pattern (call WriteStateAsync after a state change), your state will be correct. In my blog code, I await successful completion of the message on the client. If something went wrong in Orleans and the state isn't persisted, that promise would be rejected, and it could be shown to the user.

josteink 10y ago
> often visual studio will tell you that your change requires a full application restart I suspect this is due a .NET runtime limitation. When you edit your code, as long as you only make modifications inside a method which does not alter the method's declaration and method-signature, you should be fine. Basically, editing compiled code is fine, as long as you are just altering the methods internal IR-code. If you however end up doing something which alters a method's name, or signature in any way, you end up effectively mutating a class-definition. And there's no part of the .NET runtime which allows that. As a workaround, you could generate a new class on the fly, but then you would have to update all the existing references to this class in the code... And that probably means invalidating some type-signatures across the line, causing new class-level mutations. And when all that is resolved, then you would have to port and preserve state for your mutated classes, fake a new stack, etc etc. And then you have turtles all the way down. Basically at this point, a full recompile is probably the only sane option. It's a by-product of the static nature of the languages and runtime. I suspect the same applies to JVM based edit-and-go features in Java IDEs.
vmarsy 10y ago
Thank you for your reply :)

josteink 10y ago

> often visual studio will tell you that your change requires a full application restart I suspect this is due a .NET runtime limitation. When you edit your code, as long as you only make modifications inside a method which does not alter the method's declaration and method-signature, you should be fine. Basically, editing compiled code is fine, as long as you are just altering the methods internal IR-code. If you however end up doing something which alters a method's name, or signature in any way, you end up effectively mutating a class-definition. And there's no part of the .NET runtime which allows that. As a workaround, you could generate a new class on the fly, but then you would have to update all the existing references to this class in the code... And that probably means invalidating some type-signatures across the line, causing new class-level mutations. And when all that is resolved, then you would have to port and preserve state for your mutated classes, fake a new stack, etc etc. And then you have turtles all the way down. Basically at this point, a full recompile is probably the only sane option. It's a by-product of the static nature of the languages and runtime. I suspect the same applies to JVM based edit-and-go features in Java IDEs.

vmarsy 10y ago

Thank you for your reply :)