Fakka - F# Akka and the role it could play for f# broader appeal

[Simon Skov Boisen]

Hello,

At NDC 2013 I will be giving a talk on F# agents entitled 'Building clean cohesive and concurrent systems with f# agents'. That together with the communities wishes to really solidify f# as a language with distinct business-friendly features that Microsoft should be prioritizing more heavily has gotten me thinking that something like more featurefull agent-framework akin to AKKA would fit well with MS' overall strategy of cloud through Azure.

These are some of the more obvious features of AKKA (and erlang) that I think is missing in f#:

* Durable mailboxes
* Distributed agents
* Supervison in a agent-tree

Now supervision-trees I believe can be implemented on a local machine with relative ease but it gets much harder when your supervising remote agents.
The distributed messages faces smallish challenges of serialization of Discriminated Unions and bigger once with the ability to guarentee at-least-once delivery.
Durable mailboxes would just be nice to have built-in to the language but can probably be implemented by having proxy-agents that sit in front of other agents and record the messages to disk, forward the messages, waiting for reply and the removing it on succesful. In the event of a crash some govenor/supervisor of the actor-network would be responsible for rewiring the actor-network and starting both processing and persiting actors in the right order.

How viable do you guys and girls think it would be to implement these features in a framework without additional language support but building on the existing mailbox processors? Maybe the distributed and persistent part of the equation could be solved by utilizing something like MSMQ or RabbitMQ but then were slowly moving away from the lighteweight actors that we know from f#, scala and erlang and more into the domain of more traditionel and more heavyweight (both in terms of size and complexity) messages queing systems.

Hope to hear your thoughts

Regards

Simon, Denmark

[Michael Newton]

As a building block on the messaging side, there is: https://nuget.org/packages/NetMQ , a pure .net zeromq implementation that I was thinking might play very nicely with agents in F#.

Michael

--
--
You received this message because you are subscribed to the Google
Groups "FSharp Open Source Community" group.
To post to this group, send email to fsharp-o...@googlegroups.com
To unsubscribe from this group, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource?hl=en

---
You received this message because you are subscribed to the Google Groups "FSharp Open Source Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dave Thomas]

I think it is very feasible but I wouldn't build on top of the MailboxProcessor, inherent in its structure is an unbounded queue which would likely cause issues, also scan functionality can can hard to predict and requires another unbounded queue.  Both of these should be address first before building up.  

Aslo theres the question of essentially writing another Erlang...

You could swizzle this around and work on providing agent that works across the network from Erlang endpoints allowing the Erlang supervision network to do its job.   .Net doesn't even do a slightly good job of handling failure, I think thats the important thing to remember.

[Don Syme]

I think this would be a great thing.

 

Like Dave, I would encourage anyone working in this area to be open minded about adapting/extending/simplifying/… the MBP design based on the needs of a distributed agent system.

 

Cheers,

Don

 

p.s. My gut-feeling is that an Erlang + F# brew is unlikely to be broadly successful. Technically .NET can surely do at least as well as JVM-based systems here, if not much better.

[Dave Thomas]

Its not that I think its a bad idea, it just the amount of work required to build it, and most importantly debug it.  I know first hand that a project like this without a product backing it, will likely spin.  

Ryan and I put together a feature list that was akin to akka for fracture-IO vnext but without a definitive product to build out for, and with the total F# space being rather small there was not a great deal of demand or interest.

[Tomas Petricek (Info)]

I agree that having something like “F# Akka” would be a great thing – and I think I understand Dave’s worry that this would be too much work without a product baking. But at the same time, I think there is a good way forward –

 

I think the key is starting small – instead of building a framework that can do everything we may need, let’s just take the pieces that are already there, put them together, document them and let people contribute. This is an approach that worked quite well for F# Data library (I built the initial mechanism and a number of people already contributed and used the library in practice).

 

I think that for something like Fakka, the right platform would be the F# Enterprise library started by Colin Bull & Simon Cousins (at eOn – and I think they actually use it):

 

·         https://github.com/colinbull/FSharp.Enterprise

 

The library implements agent for Rabbit MQ, agent for Web Sockets and I think it is a natural place for hosting other agent-related work. There are also some assorted agents in FSharpX that (mostly) I wrote and that could be migrated to F# Enterprise (I’m happy to contribute some documentation):

 

·         https://github.com/fsharp/fsharpx/tree/master/src/FSharpx.Core/Agents

 

Together with async sequences (also in FSharpX at the moment), I think this would give a really good foundation for “Fakka” style library. Surely it does not implement everything that Akka does, but it would be a great starting point for those interested  - and I’m sure there is a lot of people who would be happy to contribute once they see some activity in this area (and once there is some coordinated effort of manageable scale…)

 

Tomas

[Dave Thomas]

Ryan and I are considering 'rebooting' Fracture as Fracture-IOI to have a smaller concise feature set, its just getting the time! :-)

[Ryan Riley]

Yes, any help on the project is appreciated. We also have some nice logos ready.

Also, Fracture-IOI stands for Fracture I/O Interactive (remote agents, hot-swapping code, etc.)

[Anton Tayanovskyy]

Hi,

On the surface, Akka looks quite nice, thanks for the pointer, I did
not know about it!

Another big implied feature in these systems seems to be a uniform
address model and automatic message transport / routing. I really
missed this when working with F# on Azure. I naively expected
communication between processes on different nodes to be a no-brainer,
which it is not. Queues came the closest but seemed to be focused on a
different scenario (message delivery guarantees), and they are not
directly tied to processes (agents).

Would certainly appreciate and use a library that solved this problem.


Thanks,

Anton

[Anton Tayanovskyy]

Hi,

To clarify, Simon starts the thread with this feature list:

* Durable mailboxes
* Distributed agents
* Supervison in a agent-tree

I think (perhaps a little naively) I can program durable mailboxes and
supervision with relative ease on top of a communications framework
with Erlang-style guarantees. I am also prepared to handle
serialization. So the core functionality I am really missing (and I
think is non-trivial) is:

type data = byte array

/// universal process ID
type pid

/// sends a message with Erlang-style guarantees
val send : pid -> data -> unit

/// spawns a new process and returns its ID
val spawn : (pid -> unit) -> pid

/// Identifiers need to be serializable so they can be passed around
val serializePid : pid -> data
val parsePid : data -> pid

I would also want some global "name server" or discovery mechanism so
different processes could find each other (discover PIDs by name), but
I think that should be doable with relative ease with Azure Storage.
Supervision / liveness can be checked by some "pulse" protocol.

Anyone knows of a good way to build this? Using in-process routing as
an local optimization with the default using global queues?


Thanks,

Anton

--
Kind Regards,
Anton Tayanovskyy

WebSharper™ - type-safe JavaScript in F#
http://intellifactory.com

[Eugen Hotwagner]

Not sure how relevant this might be but there is an extension for rx which among other things deals with networking: http://rxx.codeplex.com/wikipage?title=Networking&referringTitle=Documentation

 

[Ryan Riley]

Yes, and the ObservableSocket is built on top of SocketAsyncEventArgs. Dave (@7sharp9) and I looked at this a little in the past. I looked at this in the past, but I'm not too sure about perf. Never profiled it, but it appears there are a lot of allocations, especially in parsing. (Not that it's any different than my own, current solution using iteratees.

Nevertheless, it could be useful as a place to start.

[7sharp9]

It comes down to allocations, anything that allocates excessively will have poor high throughput performance due to the garbage collector working excessively .

[hm]

Simon,

I haven't been checking this forum for a while, and this thread is about a month old. So not sure if you have made any further progress since.

Anyway, I'd be interested in (actually: I am) looking into suitable abstractions and foundations for a message-based distribution framework for F# as well. Important aspects for my own applications are proper handling of back pressure, dynamic topology changes and fairness and priority management for the underlying scheduling.

If this is a project you'd still be interested in setting up and are looking for helping hands, please let me know.

- Martin

[Colin Bull]

Hey All, 

In the past week or so I have had sometime and began looking at this. The code can be found at https://github.com/colinbull/Fsharp.Actor.

At the minute, the following features are in a working(ish) state,

• Remoting bit is built around Fracture (https://github.com/fractureio/fracture) this seems to work quiet nicely, but I have no idea weather the way I am using it is the intended usage pattern, or not.
  
• Supervisors
• Dynamic Behaviours

There is still lots and lots of work todo but let me know what you think. 

Cheers

Colin

[log...@gmail.com]

Read through the code and it looks nice. Thanks for doing it Colin.

The message queueing transports are great for their properties; durability, availability, hub-and-spoke topology, message schema versioning, retrying and so on, but I think they are not necessarily core to an actor framework.

I think such transports should be in a library to the side of FSharp.Actors; but not necessarily for actor remoting, but for spawning actors in response to messages coming in, so that messages coming in from the message queues activate a mesh of actors inside the receiving application.

Implementing a bus in a on-the-side lib is easier with than without actors. A bus is basically a supervisor state machine, starting in config/init, going to running, then to shutting down. It consist of n endpoints, each with a transport actor. The transport actor can be restarted and then cleans up as much as possible before doing a restart; and transports can fail in a large number of ways. Endpoints post/hoist messages to the actor framework that implement the receivers.

[Simon Skov Boisen]

Hi Colin,

I also looked through the code at it does indeed look great. Even if it's still in a very early alpha state I'll include it in my talk as a demo of how you can use F# to do distributed and supervised actors. I hope I can find the time to contribute back to your great effort. Let me know if you have any specific tasks on the drawing board - maybe you could use the github issue track to help people get a feel of what's to come and what needs to be done.

Best regards

Simon

[Colin Bull]

Hi Simon, 

Thanks, if you have any specific samples from your talk, feel free to include them in the samples directory. It is always good for a framework like this to have lots of samples and docs :)  

As for future work I fully intend to put everything on github issues/ pages. I'm still experimenting with the API after using it a little I have noticed some things that could do with a change. 

The biggest problem at the minute is the amount of time my day job takes up, but I will do my best to get a list of things in the issues ASAP.

Cheers 

Colin 

[Mathias Brandewinder]

Hi Colin,

I thought it might be worth pointing out that Chris Patterson had begun working on an actors model in C# a while ago:

https://github.com/phatboyg/Stact

The reason I thought it might be of interest is that

1) Chris is an awesome guy, with a plethora of good open-source projects (MassTransit, TopShelf...)

2) he is interested in the topic, but I believe he is not actively pursuing development on Stact right now, in part because of the scope of the effort required to get it in a solid state.

It might be a good idea to reach out to him, if only to get his input, and potentially see if he would be interested in joining forces... If need be, I can help make introductions, he moved to the SF area recently.

Cheers,

Mathias

[Colin Bull]

Hi Mathias 

This is definitely of interest haven't looked at in a great amount of detail but it looks like it shares a lot of the same ideas as Fakka. 

I'll definitely reach out to him.. If you can make introductions then that would be great.

On that note any feedback and contributions are welcome. I realize that this is potentially a huge project.

Cheers

Colin 

[Keith Dahlby]

Looping in Chris

Here's a presentation on Stact from Oredev: http://vimeo.com/36279100

--

[Howard Mansell]

A thought on Fakka and the general F# community.

It's notable that Akka is written in Scala but architected to be usable from both Java and Scala.  There's a tendency in the F# and Scala communities to think that anything from the C#/Java world is no good and needs to be rewritten.  Similarly there is a tendency to build libraries that will only work from F#/Scala.

I think it would benefit the F# community to be more open and inclusive so that libraries are written to work well from C# (and even VB) as well as F#.  An actor library should be one of these.  Now, of course, it will be nicer to write apps using an actor library from F#.  That means these libraries become more of a gateway for C# developers to get on board with F#.

Just my 2c.

[Chris Patterson]

I would definitely suggest including full support for C# (as well as F#). The wider community would benefit, and like you said, offers up a gateway drug towards the F# community.

As KD said, the /develop branch of Stact is the current state of the rewrite, but it's not completely off the ground yet. There is a lot of convention at work, that probably doesn't fit well into the F# way of thinking. I'm happy to discuss some of the ideas behind the approach, if anyone is interested.

Chris Patterson

@PhatBoyG

[Dave Thomas]

There's already two Microsoft owned actor libraries, it's tricky to position something else in this space, unless there are compelling features, it might be wise to try and leverage or layer on top of those too. 

[Howard Mansell]

Agree completely.  If there is some existing library that does what is necessary but just needs a layer to adapt it to F# idioms, that is clearly a good way to go.

What are the MS offerings?  From my (limited) investigation I didn't see any clear winner in the .NET space.

[log...@gmail.com]

I haven't been able to find an existing library that implement the same primitives that Colin has implemented, so I think it's a great way forward to build an all-out F# library. Stact is nice indeed, but it's not that easy to work with, unfortunately.

C# interop can be added when we have something relatively stable as a separate nuget IMO. Some of the F# idioms are simply better than what C# can provide; mutually recursive functions as state machines being one of them - it makes code simpler to read and reason about than conventions do, despite being as short or even shorter.

[7sharp9]

TPL Dataflow is an actor library, and does a pretty good job, I used it to mimic the MBP Api on my blog, Ive also used it commercially with F# although I can't publish that as open source.

ActorFx is another one which is currently only alpha, its part of Microsoft Open Tech.  

[Don Syme]

Hi Howard,

 

One problem is that there are other major things that can compete for the time of F# library/framework developers.  For example,

·         Having the library design used and reviewed by other F# experts

·         Running and regularly testing across multiple platforms

·         Well documented with samples and tutorials

·         Usable across various .NET factorings (Windows Apps, Windows Phone, Xamarin.Android, Xamarin.iOS etc.)

·         Usable when F# is compiled to JavaScript (with WebSharper or FunScript)

 

Relatively few frameworks tick off all of the above technical criteria (it would actually be interesting to regularly measure which ones do). I can certainly see why “designed and validated for use from C#” slips down the list. 

 

Also, it seems surprisingly hard to communicate the existence of frameworks to the C# community (even C#-developed frameworks), let alone get significant uptake. While the community is massive, it is also de-centralized (or, perhaps, simply very focused on and responsive to what Microsoft says and does). There is no csharp.org, nor any real mailing lists for C# that I know of.

 

There are www.reddit.com/r/csharp/ and stackoverflow, I suppose. But for an Actor library, how would you reach a substantial density of C# programmers interested in distributed and scalable programming (while avoiding the many who really don’t need or want the technique)?  Perhaps Chris has suggestions?

 

Note things like ServiceStack overlap with the distributed-programming space, as well as the frameworks mentioned below.

 

Cheers!

Don

 

 

 

From: fsharp-o...@googlegroups.com [mailto:fsharp-o...@googlegroups.com] On Behalf Of Howard Mansell
Sent: 05 July 2013 17:49
To: fsharp-o...@googlegroups.com
Cc: Chris Patterson
Subject: Re: Fakka - F# Akka and the role it could play for f# broader appeal

 

Agree completely.  If there is some existing library that does what is necessary but just needs a layer to adapt it to F# idioms, that is clearly a good way to go.

[Veikko Eeva]

sunnuntai, 7. heinäkuuta 2013 3.01.10 UTC+3 7sharp9 kirjoitti:

TPL Dataflow is an actor library, and does a pretty good job, I used it to mimic the MBP Api on my blog, Ive also used it commercially with F# although I can't publish that as open source.

ActorFx is another one which is currently only alpha, its part of Microsoft Open Tech.  

I didn't see this one mentioned, so I include it here for the sake of completeness. Microsoft Research has also created Orleans:

Orleans is a software framework for building reliable, efficient and scalable cloud applications. Its programming model is based on distributed virtual actors, which are isolated units of state and computation that communicate through asynchronous messages. Orleans has two design goals: to greatly simplify the development of cloud applications, and to ensure that those applications are effortlessly scalable and reliable.

Apparently it has already been used in industry judging from the Halo development video here. I'm not sure regarding the license, schedules or so forth. Or for the matter, how deeply Orleans taps into Azure network stack (e.g. does it use something like RIO, RDMA or SDN trickery?) or how usable would that be on distributing load on private datacenters and user PCs.

I too have used TPL Dataflow to make efficient use computing resources on a single server and interact with another one over the Internet. It alleviated error handling and made coordinating processing easier as opposed to by plain tasks. It could be one option to build machinery regarding distributed computing. As far as I can see with my rather limited understanding.

[Henrik Feldt]

Hi,

I'm hosting a meetup where we'll look at bit at this framework:

http://www.meetup.com/sweden-progressive-dot-net/events/134311412/

If you are interested in joining, come along! I wouldn't mind if you broadcast the existance of the event either ;).

@Colin: What branch is most usable/stable? Do you plan on writing all queueing around the disruptor?

Regards,
Henrik