Orleans – Distributed Actor Model | Hacker News Reader

Orleans – Distributed Actor Model

github.com

36 pointsus0r19 comments

https://groups.google.com/forum/#!topic/akka-user/C0WGdTs2gy...

"One other thing is that the way these entities are presented to the user is via static nominal interfaces, which precludes the kind of freedom an Actor shall have according to the model (technically it also fails on the count that actors can create other actors, so it only implements message passing and misses actorOf() and become()). Therefore I would not call it an implementation of the Actor Model."

http://www.infoq.com/news/2014/07/approaches-actor-model-net

"Sergey answered by claiming that Become is just one way of reading the definition and therefore not a requirement of the actor model."

PS: having been burnt with WPF and XNA, I would rather go with Akka.NET:

1) not likely to die;

2) cross-VM (CLR, JVM);

3) based on the "standard" interpretation of the Actor Model.

I get what you are saying... I'm just wondering why you feel burned by WPF. They've recently announced that it will be under active development for many years to come. Granted, they've announced new application models, but they haven't abandoned WPF.

Akka.net has been developed as open source for longer and benefits greatly from that, but Orleans is open source and is being used by internal teams at MS...im not sure how that really compares to the uses of akka, but its not really "abandonware".

Some .NET devs tend to separate WPF from the XAML stack.

Personally I never though of myself as having WPF skills, rather XAML stack skills.

All the concepts, XAML, bindings, MVVM, ... are applicable to WPF, Silverlight and Metro, even if the APIs are a little different.

That's kind of what I have always thought would be a reasonable way to approach it...I'm not doing UI development,so I can't speak to the API diffs. Are there major gaps in functionality?

So far I have stayed on the WPF side, but from I have dabbled, some ways how bindings work and support for Blend interactions.

Do you notice any major time gaps between WPF team blog posts here?

http://blogs.msdn.com/b/wpf

Like 4-year gap at the top? I have switched to ASP.NET Web API within that gap. That kind of silence killed any trust, that cannot be fixed by appointing some unknown manager and adding a couple of minor features. What is active development? Azure is in active development. Asp.NET is in active development. WPF is barely alive.

People are still building software that makes real money using MFC and ATL. Maybe the feature set just matured? I'm not saying it doesn't need improvement...like Windows forms...people still make money with it.

It's not like knowing XAML became useless...the new app model uses it as well.

People can make any money they want with any technology - even COBOL could work for business. As an employee I want very good money _and_ a broad set of opportunities (not some unicorn maintenance gigs).

It's not like knowing XAML became useless... More like the whole world moved on to HTML (no matter how crappy it is and it is very). Where are the WPF Disciples? Where are the XAML Disciples? Where are dozens of XAML GitHub repos? Just the tumbleweed rolling across the desert...

Microsoft has another active & mature project aimed at simplifying concurrency heavy applications. Its called TPL DataFlow [1].

It gives you simple & intuitive primitives which you can use to build higher level abstractions (one of them is actor model)

1. https://msdn.microsoft.com/en-us/library/hh228603(v=vs.110)....

That's really interesting. I love TPL...i need to check this out.

TPL DataFlow is great for orchestrating concurrent computation in individual apps. Orleans is designed to be an application programming framework for the cloud - distributed, fault tolerant, and scalable. Personally, I like how Akka (JVM) builds on top of its actor model to provide dataflow programming. Orleans is not a primitive actor framework like Akka - it does the hard clustering and fault handling for you. Orleans is not a trivial library and introduces a number of constraints on an architecture that leverages it. That being said, it makes getting started much easier, depending on your goal. What is really nice about Orleans, is that the programming model exposed to the programmer is still just the TPL async/await goodness.

Does anyone have any insight into how Orleans handles failure? The only mentions I found in the documentation suggest that "grains cannot fail", which seems fairly odd to me. What about exceptions? Can grain state become corrupted? How does the system recover? Is there anything like Erlang's links or monitors here? Are supervisors relevant at all in this system?

There was a build 2014 session on how it works...it was pretty in depth. The video is on channel 9.

I couldn't find the original but this gets into it a bit:

Using Orleans to Build Halo 4’s Distributed Cloud Services in Azure http://channel9.msdn.com/events/Build/2014/3-641

In Orleans an actor cannot physically fail, just like an object in a process cannot fail. If an unhandled exception is thrown by actor code, the runtime will deliver the exception to the caller and break the TPL task of the call. Actor code is free to logically fail, e.g. by catching an exception, detecting an internal inconsistency, etc., and can handle such a case any way it wants. For example, it can set an internal failure flag and/or ask runtime to deactivate it immediately.

I guess it's a bit of a philosophical question - what is considered a failure. Orleans doesn't impose its own definition of that on actors.

Can Orleans grains within a single thread share state without message passing via the interface?

Grains are not supposed to share state directly and are expected to only use message passing. But the runtime, being just a .NET library, cannot enforce this rule. So it's merely a convention, which is trivial to violate if necessary. For example, for sharing an immutable piece of state within a silo.

Thanks for the clear reply. I also read your paper. Immutable should be adequate for avoiding the serialization tax in hybrid applications that need 'symmetry breaking' of location transparency.

Curious how the interfaces required in Orleans compare to typed actors coming in Akka 3.0

Reply on news.ycombinator.com