also guys, what is the state of the Paket in akka.net?
also, IMO we should have a meeting regarding Paket and Migrant, not stuff we can decide too lightly
Hey all, I'm trying to assess the use of Akka.Net in production. Currently, I'm looking at some sort of DDD approach with async / non-blocking IO operations for all my logic components, and I just feel that Actors is the space that I need to be in right now. I am also likely to have scaling problems, so the actor model seems even more viable. Is the current Akka.Net version stable enough for production?
They do use reflection emit heavily so i think they have perf under control. But Ill check it out
Key contributors are not online whole day I suppose.
Hey guys, I'm writing a simple tool to stress-test one of our apps, I'd apreciate a hint on how to measure the execution time of the HttpClient and attach it via PipeTo? (currently I'm piping the HttpResponseMessage :worried:
using (var client = new HttpClient())
{
var request = new HttpRequestMessage(msg.HttpMethod, msg.Uri);
client
.SendAsync(request)
.PipeTo(Self);
}
Hey guys. Love Akka.net so far and working through the bootcamp... Are any of you aware of any decent code demos / articles on Akka for games? I can only find very simple examples, which don't really address the issues I'm thinking about, mainly sharing /maintaining a single state of the world between each of the players/AIs. Each AI will need to know the state of the world in order to make decisions, and I can't think of how this would work without having some central MapActor that each AIActor has to ask/tell everything, which would seem like the MapActor ends up being a bottleneck. Is this one of the cases were Akka isn't necessarily a good fit?
@mmisztal1980 you can create a custom response wrapper in SendAsync continuation like:
using (var client = new HttpClient())
{
var request = new HttpRequestMessage(msg.HttpMethod, msg.Uri);
var start = DateTime.UtcNow;
client
.SendAsync(request)
.ContinueWith(task => !(task.IsCancelled || task.IsFaulted) ? new SuccessfulResponse(task.Result, start: start, stop: DateTime.UtcNow) : new FailedResponse(task.Result, start: start, stop: DateTime.UtcNow) ,
TaskContinuationOptions.AttachedToParent|TaskContinuationOptions.ExecuteSynchronously)
.PipeTo(Self);
}Task continuation options are used here to not spawn separate tasks for one simple operation (creating message wrapper), we attach it to task running SendAsync instead.
also depending on how big the state of the world will be and it's ability to be partitioned (maybe actor don't need the whole state, only slice of it), the different strategies may apply
@DamianReeves
- Don't introduce concurrency on an actor level. You'll introduce all problems of concurrency actors are supposed to solve. If you have long running tasks, isolate them in dedicated actors.
- PipeTo is used by and actor to keep up with task completion acknowledgements. You can use it without problems.
@Horusiath thanks. Point 1. has been my preferred approach, but I wasn't sure if something else was preferred.
So if I need to write a file from records in a database I do:
So if I need to write a file from records in a database I do:
- Create an Actor for the whole process, lets call it DataWriterActor
- Create a child of DataWriterActor called DataExtractor
- Do data access in DataExtractor
- Tell parent of results
Is this the recommended approach?
or is it like the actors host the tcp endpoint?
@GeertVL all of these issues are available for work - we'd really appreciate your help with them: https://github.com/akkadotnet/akka.net/labels/akka-remote
but even in the event of an unplanned termination, you should still get the deathwatch notification
@GeertVL yeah, I couldn't merge it into
dev due to a merge conflict - asked you to do a rebase on dev a couple of weeks ago and never heard back
which would have resolved the issue
no worries man
you didn't do anything "wrong"