@Horusiath Akka.Persistence What I should have asked about the use of
protected readonly LinkedList<CancellationTokenSource> PendingOperations;was why did you use a linkedlist instead of a normal List? Also I was thinking of abandoning what I was working on and build on top of Akka.Persistence and I was wondering how closely did you adhere to the JVM Akka? Do you think there is room to add support for projections or is there something there that I am not seeing that addresses this ? I have a use case that I think would be ideal for Akka.net but I need to Get a read model projected from the events. Basically a UI would feed click events at a rapid pace back to an actor for each current user session. That actor would persist the incoming event and once that value is stored a projection gets generated. I know this something that I can accomplish several ways but I wanted to be sure that I am not duplicating any effort.
@jcwrequests
- I used LinkedLists, because in this scenario they seems to fit better (expected behavior is a churn of lot of tempary stored values, often added and removed).
- Akka.Persistence is right now very close to Akka JVM. Notable differences:
- AtLeastOnceDelivery is called GuaranteedDelivery (this will change soon, Typesafe guys didn't appreciate this difference ;) )
- Akka on JVM is right now rewriting read side of persistence plugin using reactive streams. We have still good old fashioned message driven views.
- In your case you'd like to combine persistent actors with persistent views. Difference is that PersistentActor can both read and write to event stream specific to target domain entity, while PersistentView is read only. Moreover you can have many different PersistentViews for the same event stream, each of them may generate different read model based on the same set of events.
@rogeralsing That async await issue I ran into a few days ago? I created a reproducable test case. https://gist.github.com/Danthar/d1fe5581a6ba13ca6e30
@Danthar and it still fails using the source code from the dev branch?
Yes with the latest dev bits, excluding those stopwatch bugfixes (last 2 commits)
@rogeralsing if there is anything i can do to help, let me know.
Ok I've found the issue and have a working fix for it, but there is a bit more to it, it looks like the task scheduler propagates over to the asked actor also, even though it isn't supposed to use that.. which I find super strange
Looking around in code. Am I correct in stating that Ask simply publishes a message to the mailbox of the asked actor ? (with a temp actor as the sender)
the temp actor holds a TaskCompletionSource that gets set once the Asked actor replies
Yeah I see. When you said the task scheduler is propagated, I figured your starting a Task on the same context as the asked Actor is being asked.(without explicitly specifing the Task Scheduler) Which would explain the issue you are seeing. But that seems not to be the case here.
//the task scheduler is active here even though it shouldnt be
private void Working()
{
Receive<ChildActor.ChildCompleted>(work =>
{
_askSource.Tell(new WorkFinished());
UnbecomeStacked();
});
}
as the _askSource is the temp FutureActorRef, the TaskCompletionSource will be completed under the active TaskScheduler, which it shouldn't, so we enter the TaskScheduler but there is no ambient state present
brb. lunch time here
in this case, the _askSource is the TopLevelCoordinatorActor, which I would expect to run under the default Akka TaskScheduler..
np. here as well soon ;) smaklig måltid
protected override void QueueTask(Task task)
{
var s = CallContext.LogicalGetData(StateKey) as AmbientState; //<-- this fixes the issue, but thats a bad hack and I have no idea what consequences that has
if (task.AsyncState == Outer || s == null)
{
TryExecuteTask(task);
return;
}
aah. Could it be that there are Tasks not created through the ActorTaskScheduler ?
that would explain why its being queued a Task which does not have the AsyncState Outer
If somewhere along the line a Task is created not using the ActorTaskScheduler.RunTask then that would explain why AmbientState is null.
But isn't it normal, that when I am asking from inside an Actor, that the TaskCompletionSource would be completed under the ActorTaskScheduler as well ?
yes, I saw that it was the taskcompletionsource for the TopLevelCoordinatorActor so that looks correct, and I figure that the context is null because the completion is initiated from the outside, from the futureactorref that does not have a context.
so I just have to digest this a bit mentally :) but I think its all correct, we just need to have that null check in the QueueTask method
well I just finished a testcase with 0,5 million messages. And it works perfectly as far as I can tell.
Its not the testcase with the nested Ask though. Needed to have a work supply for that first
the async await bits have been a real pita tbh, so many edge cases, lacking documentation from MS on the infrastructure.
but since the gist code works with the fix, I expect there should be no problems.
True. It took quite a while to get a handle on what async and awaiting and continuations actually do. Besides making things magically work :P
Its fine as long as you only have to work with the top level API. But when you starting implementing your own awaiters and TaskSchedulers, things get complicated.
I avoid it. But then, I never find myself in the situation where im thinking, gee, I should really build a custom TaskScheduler for this :P
nested ask bulk scenario works as well @rogeralsing So as far as I can tell your fix seems to be solid.
#855 To track this issue. @rogeralsing if you want I can do a PR with your fix in it.
Leaving it open for today at least so others can join the discussion
Are there any docs on using DI outside of the ActorySystem (through Context.DI())?
I'm just confused on how to construct an actor, with dependencies, if DIActorContextAdapter.ActorOf<T> has the "new()" contraint.
I'm thinking of creating some actor that would control http endpoint giving out custom JSON info on request, but y'know
Trbngr there is an issue for that, i think the fix is already merged, removing the new constraint
:lightbulb: moment. If i create my actors via actorsystem at startup, will they be available downstream with deps?
will try ;)
@utrack there is https://github.com/Aaronontheweb/akka-monitoring for monitoring. Not sure if that helps your usecase
StatsD... Awesome :+1:
Build you some dash boards with Grafana and you have a wonderful view into your Actor System:)
@annymsMthd uh, any tips on how to point the monitor to statsd server? :)
@utrack
in your app or web config
<configSections>
<section name="statsD" type="NStatsD.StatsDConfigurationSection, NStatsD" />
</configSections>
<statsD enabled="true" prefix="dev.">
<server host="localhost" port="8125" />
</statsD>in your app or web config
@scottmeyer no, unfortunately we're not wire-compatible with them
that would require having the two projects agree on a serialization standard that's platform-independent
which is tricky - JVM is big endian and CLR is little endian
what you can do though is still make a .NET client to talk to a JVM Akka cluster using Akka.IO
akka.net has decided on protobufs correct? i thought that was platform independent
akka.net uses protobuffs, but those parts of the messages only contain the meta-data
the actual content of your message, the user-defined objects, gets packaged up as binary JSON
using JSON.NET
and your message is the letter
is akka.io another package? where can I find more info?
akka.io is another package - it's a uniform network interface for writing to an akka cluster over HTTP, TCP, and I think UDP
without having to actually write code that participates in the Akka cluster itself
if this question comes up often enough and there's demand for it
then I'm sure eventually some contributors will come up with a standardized way of making this stuff happen
@Aaronontheweb what specifics about build agent do you need for LocalDb?
I just want some step-by-step instructions for configuring and installing it
i.e. if you have a known way of doing it that gets it to work on your system
share that with me
if there's some weird config thing I need to turn on in order to get it to work right
I'd like to know that upfront
because updating the build image is a pain in the ass
just like all other persistence sql server tests passed
Hey, better late than never ;-) akka.io is just hooking up actors to TCP or UDP, nothing more. This means that you can of course implement your own protocol based on these standards when communicating between different systems or languages. (@scottmeyer)
@Aaronontheweb concerning second link to SO, I think I don't quite understand what the guy is talking about
with eventstore persistence plugin
@trbngr Are you using the eventstore in production? How do you like it?