working on syncing all of my repos to Travis now
I figure it'd be fun to switch things up a bit a give Travis a try on this repo
I am not sure if it was appropriate to add comments on the PR though
@Aaronontheweb I boiled it down to this gist. I start 2 instances of this app, reconfiguring each to point to the other one. If I kill one of them and wait for ca. 2 seconds, the first one does get the Terminated message and
Peer terminated is printed. However, if I'm too fast to restart the killed instance running on the same port, the first one gets confused, spits out the errors above and the Terminated message is not received.
@Aaronontheweb I just figured that adding
AwaitTermination after the Shutdown call fixes it both in 1.0.4 and 1.0.5 if I stop it gracefully. When killing it hard, even in 1.0.5 the behavior is same though. Of course when under my control I can try to gracefully close it down, but what if it crashes on me and gets restarted automatically ?
@rogeralsing That sounds plausible. Is there any way to confirm (find out what the UIDs are) ?
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?