just so you can narrow it down to a specific fixture
90% chance it's a test with IDisposable
XUnit and the TestKit both try to dispose it and end up racing eachother
but there's a way of making that not happen that I can show you
err, it's a test CLASS with IDisposable
Tail_chopping_router_must_throw_exception_if_no_result_will_arrive_within_the_given_time Xunit.Sdk.TrueExceptionFailed: Timeout 00:00:00.7000000 while waiting for a message of type Akka.Actor.Status+Failure
It's the only failing test in Akka.Tests
And it's reproducable
i. e. if I lauch this test it still fails
Hm, it's not a false positive
Ok, now it throws "somewhere" in external code
love the "system.core threw an exception" well yeah, thanks for that xUnit:)
I forgot about IsCancelled status
And someone expected that OperationCancelledException not to be wrapped inside AggregateException
Hi, I was looking at the potential SqlServer Persistence plugin that Bartosz mentioned to me in a thread in the google group. I was wondering if anyone knows why it is implemented using the SyncWriteJournal instead of the AsyncWriteJournal (or proxy)?
i could really do with some pointers on this jwconway/akka.net#3
its an attempt at UDP transport
ive set it up on a personal branch so you can see how I've approached it
Basically the end points seem to set up fine and I can send data to them manually but when I use UDP in a cluster the nodes don't seem to chatter
I must be missing something but can't see what
btw. calling all async await people .. critical bug in testkit async tests akkadotnet/akka.net#907
@rogeralsing just brainstorming here... one of the issues with async here is that there are too many things that need to be done to keep the state when continuations happen
you said before that you can't use sync context because it cannot override the context in asp.net/winforms environments
but at the same time, it's hard to keep the state safe using other means
@chanan I think mostly because of eventual consistency problems - which is not what you expect when using SQL database.
so, I was wondering... why does akka sets InternalCurrentActorCellKeeper from a different place instead of saving everything in the CallContext?
can't every possible state required be kept and restored from the same place at the same time?
... but mostly because of looking up for canonical akka LevelDB code. If it'll turn out that implementation should change (and probably should) anyone could easily change it without any risk of breaking changes in the API itself
I'm working on typed actor refs for F# and this looks very promising, but still there are some F# quirks that make me go gray
@nvivo we used the thread static container from the start as there were no plans for async await, nor did we know about call context. then we discivered callcontext along the way. in theory we should be able to use call context all the way.. but xUnit blows up when using call context. the test runner explodes when the test finishes
@nvivo but you are correct that this is the ideal way to solve it, if everything else behaves as it should
@nvivo and then the TestKit should work. but at least in xUnit 1.9.2, we are out of luck
CallContext has some stuff you need to be aware off.
Started digging and found a blog which explains it pretty well. Commented on the issue. I wont go into detail here, Because I would like to keep this discussion over at github as much as possible.
@Danthar just read the blog post about CallContext, thanks
Just out of curiosity, I went to see how Orleans did it, it appears they don't have synchronizationcontext. but then, I think they don't have any implicit state the same way akka does
ye, the implicit context is the root of all async evil in akka.net