These are chat archives for akkadotnet/akka.net

23rd
Oct 2016
Sean Farrow
@SeanFarrow
Oct 23 2016 06:37
Is it possible to ReHydrate a persistent actor at will. I've got a situation where I have actors modeling user searches that are persistent, These actors may have been stopped, when a search has completed. What is the best way of rehydrating this actor when needed? I could make my Searches actor persistent, which is the top level actor, but given there will be millions of searches, I'm concerned about out of memory situations.
Bartosz Sypytkowski
@Horusiath
Oct 23 2016 06:39
@SeanFarrow isn't a better to create a persistent query over a searched domain, and construct a search model from that?
Sean Farrow
@SeanFarrow
Oct 23 2016 07:00

@Horusiath Possibly, what would you do, have the top level actor (in this case representing the collection of searches) persistent? Are there any examples of using query? This might work as then this is a singleton actor in the cluster. Can I make a Persistent actor also a singleton? or is this not advised?
My only concern, is that actually performing a search entails some long-running processes, currently handled by child actors.

+

All Conversations

Activate or click this element to toggle the profile menu

Search

Favourites

People

aurelia

Home

Billing

Get Gitter Apps

Sign Out

Add a room

akka.net

96

Leave

Hide

aurelia/Discuss

@

Leave

Hide

AkkaStreams

4

Leave

Hide

Adam

Hide

Your Suggestions

SuaveIO/suave

akka/akka

mono/mono

dotnet/corefx

dotnet/coreclr

akka-bootcamp

angular/angular

helios-io/helios

IdentityServer3

validation

TypeScript

Azure/DotNetty

Your Organisations

Twitterizer

jon123 @ aurelia/Discuss

@timburrows next data promise ? not following you there

+

All Conversations

Activate or click this element to toggle the profile menu

Search

Favourites

People

aurelia

Home

Billing

Get Gitter Apps

Sign Out

Add a room

akka.net

96

Leave

Hide

aurelia/Discuss

@

Leave

Hide

AkkaStreams

4

Leave

Hide

Adam

Hide

Your Suggestions

SuaveIO/suave

akka/akka

mono/mono

dotnet/corefx

dotnet/coreclr

akka-bootcamp

angular/angular

helios-io/helios

IdentityServer3

validation

TypeScript

Azure/DotNetty

Your Organisations

Twitterizer

jon123 @ aurelia/Discuss

@timburrows next data promise ? not following you there

Bartosz Sypytkowski
@Horusiath
Oct 23 2016 07:33
@SeanFarrow I'm not sure if persistence queries have docs for .net, but sure there is jvm version. All rules apply. Persistent query is just a stream of events from the journal, that you can transform (using Akka.Streams API) to build any readonly model you want.
one of features of eventsourcing is that while you have a one entity writing a stream of events to it, you can have multiple entities that present different views on that stream of events, as long as they are readonly
Sean Farrow
@SeanFarrow
Oct 23 2016 07:55
@Horusiath, Woul you have a separate actor to do the querying?
Bartosz Sypytkowski
@Horusiath
Oct 23 2016 08:22
why not?
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 13:15
whenever I call ActorOf(), I have to pass it Props. I could actually wrap that to hide the existence of Props altogether. Are there any cases where this would be a bad idea?
Bartosz Sypytkowski
@Horusiath
Oct 23 2016 13:50
@dandago2_twitter props are used in more advanced scenarios like cluster singletons or cluster sharding. They also allow you to customize logic around your actors (i.e. used mailbox/dispatcher etc). So it's your choice
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 13:51
ok, am I correct in assuming that you won't need to use them directly for the majority of cases?
Bartosz Sypytkowski
@Horusiath
Oct 23 2016 13:52
it really depends on how you're building your application ;) But I think, there's nothing bad in having them implicitly called behind some extension method
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 13:55
yeah, basically, there's an overload of Props that takes an Expression<something>. I merely created an extension method that takes the same expression and calls ActorOf(), passing it a Props() that takes the expression.
was wondering if I should share this separately or try to add it to the Akka .NET codebase itself.
Bartosz Sypytkowski
@Horusiath
Oct 23 2016 14:13
you always can make PR ;)
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 14:40
yeah, I just like to check whether something is actually needed before taking the time to do it ;)
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 16:39
I just wrote an article about the whole Props affair and it includes my extension method. It also includes a little rant that some of you might not like, but I hope you take it in a constructive manner. Feedback is more than welcome. :) http://gigi.nullneuron.net/gigilabs/on-akka-net-actor-creation/
Bartosz Sypytkowski
@Horusiath
Oct 23 2016 20:46
@dandago2_twitter I don't think Aaron will be happy for this quote - this were different times when relations between Orleans and Akka.NET teams were not so sincere ;) I'm not a big fan of the constructors by myself as there are certain operations that shouldn't /cannot be done inside constructors, but also fact that generics inference doesn't work for them and they cannot be implicitly cast to delegates
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 20:53
generic inference? like what?
do you have an example where they are a bad idea?
Bartosz Sypytkowski
@Horusiath
Oct 23 2016 21:04
// you cannot do this...
var list = new List(1, 2, 3, 4); 

// ... but you could do that
var list = List.Create(1,2,3,4);
this is why we're have things like Tuple.Create
example of things that cannot be done inside constructors - ReceiveActor constructor, which needs to call some initialization logic after all Receive setup has been established. It had to have a workaround, as you could inherit from that class set up your own receivers, but there's no point where the object constructor could be finalized
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 21:43
I don't see what's wrong with the constructor version of the list... if you're alluding to automatically determining the generic type, .NET is perfectly capable of that
Bartosz Sypytkowski
@Horusiath
Oct 23 2016 21:43
not in the C# 6 or below
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 21:49
oh dear, it doesn't get inferred for constructors like it does for methods
okay. Specifying a generic parameter for the constructor. Is that a terrible thing?
Bartosz Sypytkowski
@Horusiath
Oct 23 2016 21:52
no, just irritating. More if you use generics a lot (some parts of akka-streams would be almost unusable without it).
also from what I remember, MS discouraged using heavy lifting logic in constructors (moving it to creator methods instead), but not many people care about it anyway
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 21:55
well, maybe it's just me that found some aspects of the API repulsive
but my whole point of arguing this is that making an API friendlier (and more familiar) to new developers will help adoption
to11mtm
@to11mtm
Oct 23 2016 21:56

@Horusiath sad thing is Aaron wasn't so wrong... in that comment the last Evangelist type at my work gave 0 shits about akka/dapper but was all about Orleans+EF and drinking the .Net CORE kool-aid.

At work, we use Static methods on some of our actors (going to move into container classes for better maintainability) that take what a dev would have to be setting vs what we want to always include in props, and wrap appropriately.

Bartosz Sypytkowski
@Horusiath
Oct 23 2016 21:58
@dandago2_twitter personally constructors vs methods are mostly matter of taste for me (just like tabs vs spaces ;) ). There are a lot more things in akka, that .NET people are usually not familiar with and may consider strange :)
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 21:59
that's interesting
my personal opinion was that Orleans seemed to have gone to great lengths to make actor model familiar for .NET developers and to make high quality documentation, things that I'm sure would make Akka .NET a lot better
I feel that that weirdness in Akka .NET isn't typically a very good thing
and I understand where it comes from
because of course it is a port coming from another language
but - and correct me if I'm wrong here - if you take a natural language and translate it literally, you often don't make a very good impression
that's how Akka .NET feels to me
it does great stuff
it just feels kinda strange
to work with, that is
and it is these things that make Aaron's comment feel really out of place
but of course I don't know everything about Akka .NET nor about how it was built, so I am more than happy to learn more
to11mtm
@to11mtm
Oct 23 2016 22:09

@dandago2_twitter It's a bit of a paradigm shift to get parts of how/why akka's API is the way it is. My very personal perception of it is that much of it boils down to folks who have to deal with internals.

Have you ever had to deal with any MS Stack internals? I have (Debugging behavior of EF or ASP.NET, etc.) You realize that you are absolutely screwed if you ever HAVE to re-implement certain things or introduce new behavior. It's a black box and if it works for you, great, but if not the further you deviate from the pattern the faster your code looks like a huge mess. There's a method in a project at work that is something 50 lines, recursively calling itself alongside a mess of reflection/activator. Why? because of the requirements of update tracking on attached/re-attached object graphs, resulting in a confused mess by the dev. he knew the method was subpar, he knew he could do it better if he could work with the EF classes differently. but he couldn't. The NHibernate version of the code wasn't even this bad. The framework -trapped- him.

Akka.net and other non-MS frameworks tend to tell you how you 'should' do it, because that's the way you should if you're using it as an end user. They will still gladly give you the 'other' way to do it, because if you want to extend the functionality somehow, you can do so in a way that is not as guaranteed to confuse people.

Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 22:14
I understand that point of view, but I'm pretty sure this was not (at least always) the case. Take the case of the ActorSystem creation that I mentioned in the article. I see absolutely no reason why that couldn't have been done with a standard constructor instead. There are other things I take issue with, e.g. many ways to do the same thing (e.g. props creation, consistent hashing key), a lot of things (e.g. DI) that feel like a patched afterthought that I see as design issues but I am not sure whether there really is a problem or whether I am merely missing something. As an API it certainly feels very strange.
Daniel D'Agostino
@dandago2_twitter
Oct 23 2016 22:24
I really dislike the use of statics everywhere btw, it makes things really hard to work with especially when it comes to writing tests