@simonpetty you can use the ITestOutputHelper from xunit, you need to add it as constructor parameter to your test class
I try to use datetimeoffset as much as possible. But that isn't always possible. When exposing public api's i often have to drop down to Datetime for compatibility reasons.
hi - is there any way to play a series of events into a PersistentFSM actor to restore its state (in a test)?
or should I use the in-memory journal and retrieve the actor from that?
@finnneuik_twitter write events directly to in-memory journal
to get default journal actor ref:
Persistence.Instance.Apply(Sys as ExtendedActorSystem).JournalFor(null)
Do things just stop working in the cluster when this message is logged? "blablabla was not delivered. 9 dead letters encountered.|"
@alexvaluyskiy I didn't see your answer about the cluster events missing on that one spec you ported
did you determine if that was an issue with
TestProbe or with the Cluster plugin not publishing events properly?
(I was offline this entire weekend)
@Aaronontheweb is doesn't related with Cluster. But you can see this message in every (successed or failed) MultiNode spec log file. I don't know, is it a bug or not
@alexvaluyskiy could be a race issue where an actor that is subscribed to cluster events terminates while a message is being delivered... but I'll take a look at the
ClusterDomainEventPublisher today
seeing some issues with clustered routers that make me think there might be a subscription issue
with that system possibly
just a suspicion I have - no data to support that right now
I'm still trying to reload state in a test of PersistentFSM actor. It looks like the state is being loaded in correctly, but then when I try to send another message to the same actor it looks like the state is back to the initial state again. I've put together a cut down example that demonstrates my problem.
Basically the actor counts and should change state on receiving the 3rd message, which I'm trying to set up with the following:
journal.Tell(new WriteMessages(new[]
{
new Akka.Persistence.AtomicWrite(ImmutableList.Create<IPersistentRepresentation>(
new Persistent(new CountedEvent(1), 1, "testActorId"),
new Persistent(new CountedEvent(2), 2, "testActorId"),
new Persistent(new CountedEvent(3), 3, "testActorId"),
new Persistent(new PersistentFSMBase<TestActorState, TestActorData, object>.StateChangeEvent(TestActorState.FinishedCounting, null), 4, "testActorId")
))
}, testActor, ActorInstanceId));The full code is here:
https://gist.github.com/finnnewick-justgiving/b0167b55a33d0259ec7907d38fbc2ed2
Any ideas? I'm guessing I'm missing something very basic as I'm pretty new to akka.net.
@Aaronontheweb I've ported all missing router specs, and even they are failing time to time. So we should start from Local Routers
@alexvaluyskiy I've noticed that both the Remote and Cluster router specs fail
for RoundRobin and ConsistentHash
I enabled all of them in my current feature branch
I took a look at the JVM base router code on Friday
and our implementation is out of date
let me grab a note I made real quick...
@finnnewick-justgiving if you want to verify replay scenario, write messages first to the journal, then use
ExpectMsg to ensure, that they have been stored, and THEN create a persistent actor. Remember that sending a message is asynchronous process, so sending events to journal and command to persistent actor will be done in parallel.
RouterConfig, RoutedActorCell, ResizablePoolCell, and others all appear to be out of date in Akka.NET implementation compared to JVM: https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/routing/RoutedActorCell.scala#L169
that's the note I took @alexvaluyskiy
I was planning on working on some of that today
how would you like to divide the labor there?
@Horusiath great stuff, almost there! The final state change event doesn't seem to be taking effect though. If I "command source" the behaviour is what I'm expecting, but the event sourced behaviour is missing the state change.
this is the line in question that's not doing what I would expect it to:
new Persistent(new PersistentFSMBase<TestActorState, TestActorData, object>.StateChangeEvent(TestActorState.FinishedCounting, null), 4, "testActorId")
@Aaronontheweb I've made WIP PR with my router specs akkadotnet/akka.net#2049
@finnnewick-justgiving have you made sure it has been written to journal? Also what are you using this null value for?
@Horusiath the null is the timeout value, which is a nullable value, setting it doesn't seem to make any difference
@alexvaluyskiy nice - which ones of those don't pass right now?
@Horusiath And yes, just checked, it looks like all the messages are being stored correctly (I'm expecting "WriteMessageSuccess" on each event and the last one is the state change event)
I'll take a look at those today
@finnnewick-justgiving what do you actually expect after this 4 event to happen?
when i then send the countcommand to the loaded actor it should be handled by a different handler
When(TestActorState.FinishedCounting, (e, state) =>
but it still seems to be behaving like it's in the "counting" state
@Silv3rcircl3 I might need to adjust some of the assertions on the Akka.Streams performance tests
running into an issue with one of the graph specs in particular where we exceed the 50ms threshold by 3-6 ms every now and then
I think the issue there is that we're running in concurrent mode now
so the specs are subject to more noise from the OS than they were previously
@finnnewick-justgiving I have no way to verify it right now, but I'd check if the behavior remains, when replayed from commands (so sending the set of commands to persistent fsm) instead of directly sending event to journal (this is fragile, as journal has no means to verify correctness of user events)
I really need to get started on that relative / historical benchmarking SaaS service soon
that would solve this problem better than tweaking an absolute deadline :p
gotta get on the road and drive for two hours now
@Horusiath if I send a sequence of commands the behaviour appears to be as I expect, I'll try wiring it up to a real persistence store and see what happens (that'll be tomorrow now)
Isn't it better to event source rather than command source though, as commands will vary based on the current implementation of a system but events are historical artifacts?
Anyways, thanks for all the help - I feel like I'm almost there!
Isn't it better to event source rather than command source though, as commands will vary based on the current implementation of a system but events are historical artifacts?
Anyways, thanks for all the help - I feel like I'm almost there!