Hi!
I consider using Akka.NET for triggering data replication.
I consider using Akka.NET for triggering data replication.
One system changed data and triggers other systems to refresh it from central storage.
Later on any system that changes data will be allowed to trigger other systems.
Later on any system that changes data will be allowed to trigger other systems.
I did a research and still not sure about the persistence. The message has to be delivered at least once.
is Akka the right choice ? I should I consider Redis for example? (or anything else)
@pawelklimczyk Take a look at Akka.Net streams
thx
@Greatsamps generally I wanted to ask if Akka is correct choice here
Has anyone used the MongoDB persistence plugin against DocumentDB/CosmosDB?
I am seeing a really weird TestKit behavior that I'll try to get a shareable code example for but I'll describe quickly here...Basically my actor is using Serilog directly (not Akka.Logging.Serilog) and if I create the actor using ActorOf in my NUnit test case I get no logging output in Nunit but if I use ActorOfAsTestActorRef to create the actor then I do get the logging output in Nunit
@DamianReeves not as far as I know
@bertlamb_twitter ok, that sounds weird
almost as though a piece of logging infrastructure isn't being correctly shared between the TestKit and the
ActorSystem
switching to
Console.Out.WriteLine shows the same behavior
so it is like somehow
System.Out is getting co-opted in the ActorOf flow
@pawelklimczyk you already know my opinion ;)
We are working with sending a cached object back from an actor to a caller. Unfortunately the cache may not have been created yet but we can't Sender.Tell() a Null. Anyone have a creative solution?
The actor is created using Generics so we don't know the data type to create an empty object to return either.
Sender.Tell(default(T)); throws a null error
@dknoodle I'd go for lazy instantiation there
or use a special-case pattern to send a backoff message to the caller letting it know to try again
in a few moments
We are using the actor itself as the cache placeholder but we don't know if it has received a copy yet and it may not in any forceable future.
I see
in that case, use a special case
send back a status message indicating that it's not available yet
it's a good practice to get into even without actors
instead of using
null for that sort of thing
have a special subtype that indicates
Empty for that particular type
@Aaronontheweb - Thanks for the feedback!