I might stay up .. I generally only finish my work around midnight anyway .. might play some xbox and then join your session
just that I have another session for another project next nigth @ 1am again
lol
oh man
that's rough
hello! I'm adding akka to an existing project and I was wondering how is progressing the changes planned for DI in #1675
does it worth to use the "old" way? or just leave DI aside and wait for the final implementation? thanks!
@luisbelloch Any changes in the DI Api have been shelved until a later release. The DI api as it is now is usable, but not ideal.
If you can integrate Akka without using DI. I would recommend doing that. It would lead to a better design
Speaking of DI, is there a way to temporarily disable the check that cast an exception when trying to create an actor with new? SimpleInjector will try to create an instance of all registered types and their dependencies, to ensure that it can actually create everything.
Maybe this is a more general question regarding NuGet packages... But has anyone else had issues with Visual Studio where methods / members in the framework seem to be inaccessible or unavailable in the IDE, but the project builds fine. I'm so confused with this - only had this issue with Akka so far, hence I'm asking here.
I should add, I'm seeing this specifically with Akka.Persistence package
@maxpaj i have that sometimes, its usually related to some cache files not being updated.
Alright... I've tried removing the packages folder and restoring NuGets again. Not working. Any ideas where these cached files could be located?
_resharper folder (if your using resharper). You .suo file can sometimes cause wierd stuff, so deleting that can help (it will be regenerated). Other then that doing a Solution Clean might help (it deletes your obj folders)
I am using Resharper, not sure where that folder is though. Tried deleting the .suo file, didn't help :(
Weird thing is, things like Command<T> and Recover<T> are visible, but the Context property contains barely anything -- just a GetOrElse() method...
Weird thing is, things like Command<T> and Recover<T> are visible, but the Context property contains barely anything -- just a GetOrElse() method...
@maxpaj I have had that happen to me. The easiest way I fix it is, go to: Tools -> Options -> Scroll to Resharper -> Suspend Now -> Resume Now.
Yeah okay, it's Resharper for sure. Thanks Scott!
All methods / members appear when I shut it off
Does anyone know how to turn logging down in the Akka TestKit?
@Scott__Martin_twitter you can pass HOCON, including logging settings, into the base constructor on the
TestKit
the other thing you can do is mute certain events
@Aaronontheweb That's what I was missing, I'll give that a try. I had tried to configure just like my non test system, but it never got picked up
Mute is a bit esoteric
but you can find examples of us using it inside our own tests
Thanks!
that eliminates certain events from showing up in the log entirely
Can someone give me some guidance on creating ephemeral actors?
This is hard to explain... but, while processing a message, I want to create a child actor that needs to work on some stuff even after I finish processing said message.
And when the child actor is finished the system needs to react.
I'
so you want a fire-and-forget child actor?
Well, kind of but the child actors parent needs to react to the child finishing it's work.
I have a few confusions.
Should I store a reference to the child actor in the parent actor?
This is kind of unrelated, but how does the actor system go about cleaning up actors?
If I create a bunch of child actors, but never reference their
IActorRefs I assume they are still alive and kicking processing anything they are sent. At what point are they killed off and memory freed?
Of course I realize that .NET is GC'd
@ronnieoverby they won't die by themselves, unless you explicitly say them to do so, or their parent will terminate, or the actor system will be shut down
Let me help myself by rephrasing the question. When creating actors, is there anything I should or shouldn't do so that I can avoid leaking memory?
@Horusiath It sounds like I need to be explicitly killing them off, which means don't throw away the IActorRef reference.
Is that right?
@ronnieoverby each actor will automatically terminate it's children if it will be terminated itself. Also you always can access children by using Context.Child(childName) or Context.GetChildren(). You can also target actors by using actor selection.
When it comes to strategy on how you can stop an actor, read this: https://petabridge.com/blog/how-to-stop-an-actor-akkadotnet/
I'm good on how to stop actors.
Okay, I think that helps. My next question is... Is it an antipattern to maintain a collection of child actors, where the child actors lifes span multiple parent mailbox cycles?
I keep finding myself needing to do this, but feeling like I shouldn't have any state stored that spans multiple messages (making my parent actor more stateful)
no, it's fine - actor model is stateful by default
:joy:
yep, totally fine to do that
haha
Why the hell does it feel so wrong?!
I think it's because I'm used to trying to keep my web apps as stateless as possible
working against two decades of stateless web application development
haha yep
the default way we designed those types of systems
was treating the web application like "hot lava" and the database, usually SQL Server, as the "safe" zone
so most developers designed their software to rifle data into some sort of data store as early as possible
with the actor model, this is flipped on its head
the database is viewed as an inevitable bottleneck and source of problems
so we'd rather use it as infrequently as possible
treat it like backup storage for our state
whose primary residence is now in our application's memory
so it's only natural that it will take time to adjust to that
works counter to how we've been doing things
Well, I appreciate setting me straight
BTW, @Aaronontheweb did you look into that bug anymore, with the priority mailbox not generating priority?
I haven't yet
fixed up some clustering bugs and finally shipped Mono support
Okay. I did link to a github project that isolates and shows the problem.
that and some Akka.Cluster.Tools issues are next on my to-do list
I'll look at it some this week - may not get to it before this release
but if it's easy to reproduce and fix should be NBD
No sweat, I was only learning Akka when I discovered the bug... don't need it for any apps.
based on our last conversation I have a good idea what it might be
design issue with the way we set the priority generator on the queue
1 more: I heard you talking about some newly added CRDT support, but don't see anything in docs about it.
there's a PR open for it, a library called Akka.DData
@Horusiath is leading that
Akka.DistributedData ;)
I've been a POS and haven't reviewed it yet
see?
still needs some polishing
Oh on the podcast it sounded like it was finally out of some beta state.
What data type is it?
my bad :(
NP
AFAIK it's what, monotonic collections and that sort of thing?
CRDTs are usually variants of counters, sets and maps/dictionaries with different characteristics based on use case
Yes, I'd be very surprised if you had implemented counters and sets and maps
I watched a video from Google going over all the various data types and there were maybe 7 or 8 concrete types he listed off
I've been following what Chris mccord has been doing with Phoenix presence, so I was interested about this CRDT support, too
This is the one https://www.youtube.com/watch?v=oyUHd894w18
This message was deleted
Okay, I'm done flooding the room :)
This message was deleted
so far we have
Flags, GCounters, PNCounters, PNCounterMaps, ORSets, GSets, ORMaps, LWWRegisters, LWWMaps
OOH that's exciting
they are already verified with specs and working - missing part is verification of correct replication across real cluster (it works locally)
also we need to make API more user friendly - this plugin has been ported from scala, which used a lot of implicit constructs and custom operators
Are there any docs/blog posts around these types?
I'd love to play with them some
only on the JVM side so far: http://doc.akka.io/docs/akka/current/scala/distributed-data.html
we'll port it too later
Awesome....
Just enabled Mono builds to run against the
dev branch
going to have them on for all PRs going forward
Will stopping an actor kill all Tasks started with Task.Run
@StandBackBurrito nope - actor doesn't know your code is running a tasks
all I needed to know
thanks
And in general, nothing can stop any task started with Task.Run, ever.
apart from cooperative cancellation via
CancellationToken
thanks for the info