the dead letters system might end up becoming a bottleneck if you're dealing with message volumes at the level where this is a concern
bugger
and then have the sender and leaf communicate directly after that if there needs to be a "conversation"
that way you only pay for the checks once
since each will hold an actor ref to each other
get a deathwatch notification
and then go back through the hierarchy again
parent can check if the child exists first
before routing the message to it
and that's the preferred way of dealing with it
"old school" code we used to be able to track multiple logs by the thread-id most of the times, now I get logs from all over the place
@Aaronontheweb Have you plan to update Persistence providers for 1.0.7? I've already made pull requests for PostgreSql and SqlServer (Akka 2.4.2 compatible) providers
akkadotnet/Akka.Persistence.PostgreSql#20
akkadotnet/Akka.Persistence.SqlServer#24
and created MySql provider
https://github.com/alexvaluyskiy/Akka.Persistence.MySql
Is it possible to move this mysql implementation to akkadotnet github account?
Hello, I just posted a question on SO where I express my unhapinnes about message boxing in F# actors. Here it is:
http://stackoverflow.com/questions/36470453/how-should-f-actor-functions-be-defined-to-avoid-message-boxing
http://stackoverflow.com/questions/36470453/how-should-f-actor-functions-be-defined-to-avoid-message-boxing
I must say while I enjoy Akka.NET F# API and prefer it to C#, this particular aspect looks better in C#.
and are you using Akka.FSharp?
unfortunately .NET type system is poor and don't have anything like Ceylon's type unions (don't confuse them with union types)
So this is partly a design question: is boxing mailbox messages a design smell (except system message case)? And if so, what is the better way? Can't see any better. They all suck :-)
@Horusiath but since your first reaction was "why boxing them at all?" and you work much with F#, does this mean that you avoid this scenario? But how? Putting all cases in the same type?
optionally in Akkling this shouldn't be necessary, as system messages have active patterns which tells exactly, that pattern match is expected to work on obj value
And your Akkling project doesn't address this?
I know it addresses the problem of untyped messages, but that's different.
I have a persistent actor which I want to be able to reset. In F# I represent its state using option type. Storing "Some state" works fine, but when I assign None state and call "exec" function, it raises NullReferenceException from Akka.Persistence.Journal.WriteJournalBase.AdaptToJournal.
I know that None can be optimized to null and that it's not possible to use null/None as a message to actor. But it should be possible to use None as state, shouldn't it?
Guys, if you interested in load testing, you can look this - https://tech.yandex.com/tank/?ncrnd=3620
@object In loot of F#-oriented DDD talks there is often mentioned something like state 'zero' which is initial state for target aggregate. It has more sense than using options, because empty state is usually needed once during the aggregate lifetime (at the beginning), so bearing the burden of marking each state as option (and checking it everywhere in business logic) may not be a justified case