These are chat archives for akkadotnet/akka.net

2nd
Apr 2015
Aaron Stannard
@Aaronontheweb
Apr 02 2015 00:32
spent all day working in Mono on my dedicated Ubuntu hardware - can confirm that Helios now runs like a champ on it. Benchmarks aren't nearly as good compared to Windows but that'll come with some time as Mono starts to reap the benefits of the CLR being open source.
going to push a new version of it and send a PR with it integrated into Akka.Remote so that can now run out of the box
jcwrequests
@jcwrequests
Apr 02 2015 00:37
I have created a repo for doing the Pull Request screencasts. It's currently just a skeleton based around contrib document. Each screencast will have their own directory and within each directory I will be putting an outline and a basic script. Once I am able to verify that the script and outline have no issues I will create an initial take and make it available through the repo and probably YouTube. One of the goals of the script and outline are to make it easier for non native english speakers to translate the content and make there own version. Again anyone interested just ping me here. Thanks...
Aaron Stannard
@Aaronontheweb
Apr 02 2015 00:37
@jcwrequests nice man!
jcwrequests
@jcwrequests
Apr 02 2015 00:40
@Aaronontheweb Thanks. I have been doing them for training new employees and getting vendors up to speed of various things for several years. So it's something I am comfortable doing and find that it's very effective along with written documentation. There is no replacement for seeing someone actually do something.
Aaron Stannard
@Aaronontheweb
Apr 02 2015 00:43
yeah, I agree
seeing someone actually do something realtime always helps me especially when it's an operational thing
jcwrequests
@jcwrequests
Apr 02 2015 00:46
It really brings certain details to light. I will be putting together some questions that I will be throwing your way in a few days around getting this whole thing setup. Talk to you soon.
Roger Johansson
@rogeralsing
Apr 02 2015 07:01
Guys, have you seen this? https://github.com/electronicarts/orbit Bioware have ported Orleans to Java :P
Arjen Smits
@Danthar
Apr 02 2015 07:11
@rogeralsing exactly. Thats what it reminded me of as well :smile:
Roger Johansson
@rogeralsing
Apr 02 2015 07:26
And they got Netflix interested in co-op. this will be fun to follow :)
The thing I don't quite get with the Orleans/Orbit stuff, why is the AP guarantees and Actor parts merged together? you might still want AP for Services w/o actor behavior..
IMO, the AP stuff should be in a separate module, and then let you host services/actors/whatever inside it
Arjen Smits
@Danthar
Apr 02 2015 07:36
AP ?
Roger Johansson
@rogeralsing
Apr 02 2015 07:37
From the CAP theorem, Available + Partition tolerant
Arjen Smits
@Danthar
Apr 02 2015 07:37
aah... ofcourse
Roger Johansson
@rogeralsing
Apr 02 2015 07:38
So imo, what really should be done is "Virtual Endpoints" instead of "Virtual Actors"
Arjen Smits
@Danthar
Apr 02 2015 07:45
Hmmm. I don't know. But im not sure if what you are saying is correct. I saw an Orleans screencast a while back, from the Halo team, in which they showed off some Orleans code. And although it all felt like Voodoo magic back then (which became alot more clear since I started with Akka). I do distinctly remember them talking about a Host which took care of all the Distributed and Partitioning stuff.
Or maybe I am misunderstanding what you mean with the 'parts merged together' bits
Roger Johansson
@rogeralsing
Apr 02 2015 07:49
Orleans does the magic partitioning / always available parts, and they are also an actor framework.. I think that should be separated
Arjen Smits
@Danthar
Apr 02 2015 07:59
Ow you mean on a framework level. Hmm. Maybe they felt that that part is, in terms of implementation, so closely married to the Orleans Actor framework, it made no sense to put it in a separate framework. But thats just conjecture on my side, however its the only reason I can think of.
Should be interesting to check out the Orleans code to see if thats true.
Bartosz Sypytkowski
@Horusiath
Apr 02 2015 13:52
IMO Akka was always a middleware framework. It is harder to learn and requires an explicit management from the user perspective, but also gives you enough space to develop higher level abstractions (such as streams, virtual endpoints, cluster sharding and many others) on top of it. But you may still dig deep down at any time when you want true control and speed and this is something you'll never get with frameworks, which have started from those higher level concepts as a base line.
David Smith
@smalldave
Apr 02 2015 14:12
@Aaronontheweb I'd wait before pulling in RemotingTerminator changes. Working through RemoteNodeShutdownAndComeBackSpec
Want me to close the pull request?
Aaron Stannard
@Aaronontheweb
Apr 02 2015 15:58
@smalldave yeah that'd be best for now then
Aaron Stannard
@Aaronontheweb
Apr 02 2015 16:14
@rogeralsing @Danthar @Horusiath yeah, that's a design decision with Orleans that I feel is very limiting - the whole thing feels extremely over-engineered to begin with, really. Actors are just tools that don't have any inherent CAP bias, no more than OOP objects having them. Orleans was built for something specific - single apps that are meant to be clustered with high availability.
Orlean's biases don't even really allow for you to network multiple Orleans code bases together without doing some really hacky shit dotnet/orleans#211
so you can't do anything like my WebCrawler Akka.Cluster sample, which uses individual roles as microservices, without having to host your connection to each service in a separate AppDomain
but you know - anything that gets .NET developers in a headspace where they're actively looking at something like the actor model is a good idea in my book
it'll raise the state of our art
Roger Johansson
@rogeralsing
Apr 02 2015 17:17
@Aaronontheweb tbh, CAP is only applicable in multi node/system environment (as the definition is how the nodes/system behave) and a single actor is never ever present on multiple machines (that would be different actors) so even bringing CAP up when talking about how actors behave indicates that there is something iffy going on.. (read multiple instances of the same thing)
Bartosz Sypytkowski
@Horusiath
Apr 02 2015 19:54

Akka and Orleans are both very mature projects (both around the same age)..

ORLY?

Roger Johansson
@rogeralsing
Apr 02 2015 19:59
Maybe they were invisible for 4 years?
Bartosz Sypytkowski
@Horusiath
Apr 02 2015 20:06
I don't want to be arrogant or start a flamewar, but to be honest, Akka.NET is based on concepts from Akka, and in further line from Erlang, both of them are heavily battle-tested in hundreds of applications over the course of almost 30 years in total. Orleans (and now Bioware's Orbit) at least for now are both 1-project based, and their are not core part of their projects - neither Halo nor DA:I are multiplayer-based. And while they introduce some incredibly useful ideas, I think it's still not a fair comparison.
And I'm not an Orleans hater - I want to see this framework growing. Variety is good for everyone.
Aaron Stannard
@Aaronontheweb
Apr 02 2015 20:09
@rogeralsing yeah I think you and I are saying the same thign
actors are actors - CAP theorem stuff only plays a role when you start distributing them across multiple processes
Roger Johansson
@rogeralsing
Apr 02 2015 20:10
Exactly
If orleans removed the broken actor constraints and just exposed always available endpoints, i would love that.
Aaron Stannard
@Aaronontheweb
Apr 02 2015 20:12
and TBH, I really wish people who talk about distributed systems stuff would stop pigeonholing on CAP - yes, for the love of god, we get it. Every system has trade offs that have to be picked carefully and deliberately. Not a fundamentally different exercise than making tradeoffs in any other software system (concurrent, embedded, etc...) - just yet another new domain where developers get their butts kicked by the laws of physics and economics over time.
Roger Johansson
@rogeralsing
Apr 02 2015 20:13
And let devs decide what to expose on such endpoint
Aaron Stannard
@Aaronontheweb
Apr 02 2015 20:13
to your point @Horusiath - Orleans has an in-house project for many years
was*
so it's "mature" from a wall clock time perspective
but not very "mature" from an odometer perspective
Orleans has one success story
so far, hopefully they have more!
Akka has tens of thousands
as it's been open and heavily used by lots of people who are not Typesafe for years
technically speaking, Akka.NET has been publicly available longer than Orleans
they have an interesting interpretation of the actor model, although what they do does not stick to the "actor model" as it's defined in the white paper
Akka.NET is ultimately an unbiased framework - you get the actor model as a single process, a couple of remote processes, a whole cluster of different processes, or clusters of processes that use persistence for greater consistency
and lots of other combinations
Orleans is a piece of off the shelf software built for specific types of distributed apps
and has powerful tools for doing that
but you give up a lot in order to get those tools
Roger Johansson
@rogeralsing
Apr 02 2015 20:18
btw. offtopic, but can you take a crash course with me on our cluster supprt? thats the module I know the least about tbh.. I know how to start up clusters and do routers, but no more :P
Aaron Stannard
@Aaronontheweb
Apr 02 2015 20:18
haha, sure thing
Roger Johansson
@rogeralsing
Apr 02 2015 20:18
not now that is, some day
Aaron Stannard
@Aaronontheweb
Apr 02 2015 20:18
I gotta head into the office and get some lunch (probably not in that order)
released Helios v1.4 this morning
has your Mono support
Bartosz Sypytkowski
@Horusiath
Apr 02 2015 20:19
we need to distribute some more learning materials about cluster and persistence
Roger Johansson
@rogeralsing
Apr 02 2015 20:19
nice :)
Aaron Stannard
@Aaronontheweb
Apr 02 2015 20:19
going to send a PR that turns it on in Akka.Remote
@Horusiath yes we do
I took a look at the persistence bits for the first time last weekend
realized I need to learn more about how they work
and also, apparently JVM Akka.Persistence now depends on Akka Streaming for reads
Bartosz Sypytkowski
@Horusiath
Apr 02 2015 20:20
Akka.Http also will be
reactive streams are a very universal concept, just like LINQ ;)
Greg Young sent me a disscussion about Query side of akka persistence and reasons for changing it
they concern a little how journals and persistent views may be implemented, but they shouldn't change a lot in persistent actors and at-least-once delivery
Roger Johansson
@rogeralsing
Apr 02 2015 20:24
Btw , we had a talk with Roland yesterday . They will wait with persistence untill streams are completed
Bartosz Sypytkowski
@Horusiath
Apr 02 2015 20:25
do you think we should manage some time for implementing akka streams from our side in near future?
Roger Johansson
@rogeralsing
Apr 02 2015 20:31
Streams and io , but damn, we need a bit of rest after 1.0 :)
Bartosz Sypytkowski
@Horusiath
Apr 02 2015 20:35
I think, that after 1.0 we should discuss and prepare some official road map for the next features
Roger Johansson
@rogeralsing
Apr 02 2015 20:39
yes
Roman Golenok
@shersh
Apr 02 2015 20:39
Hi all.
Guys, what about securing and encryption between client and backend? I see examples, such as Chat sample and what if we want to encrypt messages? (Not only text, maybe binary too). Is this custom logic only or it can be part of system (for example specify in config file property "encryption: RSA") ?
Roger Johansson
@rogeralsing
Apr 02 2015 20:40
we also found out that akka v 3 has changed into a module ontop of akka 2.x.. so the new typed actorrefs and changes to how sender is handled are now just a plugin on their end
Aaron Stannard
@Aaronontheweb
Apr 02 2015 20:40
@shersh right now we strongly recommend running your clusters inside a private network
because we don't have any out of the box security tools yet
those have to be implemented at the transport layer inside Helios
and TLS support is on the roadmap for Helios 2.0, which I will be publishing soon
(that's my next thing after 1.0, along with Akka.Cluster)
Roman Golenok
@shersh
Apr 02 2015 20:42
@Aaronontheweb , okay, thanks!
Roger Johansson
@rogeralsing
Apr 02 2015 20:42
That beeing said, as we do support surrogates on message level, you can if you absolutely need to, create custom encrypted surrogates.. this is ofc not the correct path to walk, but it is doable as you can decide exactly how the message is formatted over the wire
Bartosz Sypytkowski
@Horusiath
Apr 02 2015 20:43
hmm, this sounds like a good topic for a post ;)