public class CustomMessageExtractor : HashCodeMessageExtractor
{
public CustomMessageExtractor() : base(maxNumberOfShards: 100) { }
public override string EntityId(object message)
{
return message switch
{
NotificationActor.Subscribe sub => sub.ConnectionId,
ShardRegion.StartEntity start => start.EntityId,
_ => null
};
}
public override string ShardId(object message)
{
if (message is NotificationActor.Subscribe sub)
{
return sub.EventName;
}
return null;
}
}
string ShardId(object message)
from that class. I wonder if it should be sealed...
StartEntity
being handled, so users can see the difference
Is it possible to broadcast a message to all entities in the same shard? For instance, I want to send one message to all entities that live in the shard
Ummm I feel like there's a way to do that, let me think
.... I mean, I have no clue whether this works or would do what you need, but you could try an
ActorSelection
like/system/sharding/customer/customerupdated/*
<-- Maybe it should be /user/ but I think it's /system/
Thanks a lot @to11mtm
It is no longer needed because I went in a different direction but it is worth to try :-)
One more question, is it possible to configure the shard actor's supervision or even better tell akka sharding to use a custom shard actor?
Hey everyone. I started up a project using Akka.NET after a few years of doing the tutorial and some small projects. Right now, it's mostly just pulling stock data and inserting into a Timescale database. Probably a pretty common use case :)
Anyways, I was wondering what the recommended approach might be to creating many singleton actors. A common case will be a simple ETL style pipeline. So, some sort of coordinator/conductor actors specifying what to download and when, then a extractor actor, possibly an actor to handle api rate limiting, then a loader actor to insert the data into the database.
I have a few of these created, but right now I just have everything initialized in the main method and passed through the constructors, which is pretty ugly, so I want to fix these before I create too many more of these pipelines.
A few (well, lots of) questions:
Sorry for the wall of text of questions.
Akka.FSharp
still a thing?
await
in any class's code it's variables have to be declared as volatile
to avoid the problem you describe. The short answer is no, you should not need volatile
keyword unless your message handling code for some reason requires it.
@JarrodJ83 We're working on getting the CI running so we can properly do that.
You may want to look into the prerelease Linq2Db plugin if you want to work with latest version of Akka.Net. It's a very performant Persistence plugin that works with many databases including Postgres.
If you need a package from the org, once akkadotnet/Akka.Persistence.Linq2Db#15 gets merged there will one published. Until then, I have it self published from my fork for the time being.
It's primarily in prerelease because while specs pass, AFAIK I'm the only one who's using it in production. We would like community feedback especially in cases around the 'backwards compatibility' with the existing journals. and the Persistence Queries (which I haven't used, but all specs pass.)
But, it's pretty awesome... Scales up nicely, and I have a PR in for Linq2Db that improves horizontal batching by up to 10-30% depending on payload size :)
@Aaronontheweb regarding the TestScheduler, thanks for the hint but now I'm confused... how should I use it then within a test scenario? should I invoke it explicitly from outside the actor/test?
@crixo correct - you have to call TestScheduler.Advance
to move the time forward