await CoordinatedShutdown.Get(_actorSystem).Run(CoordinatedShutdown.ClrExitReason.Instance);
Hi Guys, I was trying to build Akka.net on my local, facing some issues. https://getakka.net/contributing/build-process.html this page looks broken. Anyone got updated link which can help me build locally?
weird
wonder if that's an old page that we moved
https://getakka.net/community/contributing/build-process.html <-- this is the new home for that page
I'll go add a redirect to fix that link
really sorry for the inconvenience @ravividap
I wonder if our DocFx deployment system is excluding those now
Another question re the Azure storage queue stream...I have it hooked up in my Actor's
PreStart override. Should I not be disposing it when the actor is terminated? I'm expecting to have to do something like myQueueStream.Dispose() in my Actor's PostStop override?
1 reply
In this sample: https://github.com/petabridge/akkadotnet-code-samples/blob/master/src/clustering/sharding-sqlserver/SqlSharding.Host/Program.cs, what is the value of registering the shard region as
.WithShardRegion<ProductMarker>(...)? Why not just register it with the specific actor type (as opposed to ProductMarker), like so: .WithShardRegion<ProductTotalsActor>().... I don't understand the benefit that ProductMarker provides? Would my Actor System be worse-off if I registered it with .WithShardRegion<ProductTotalsActor> instead?
I have an actor configured to consume an Azure Storage Queue Stream like so:
protected override void PreStart()
{
QueueSource.Create(Queue)
.RunWith(Sink.ActorRef<QueueMessage>(Self, Done.Instance), Context.Materializer());
}But I'm finding that the same message on the storage queue keeps being returned over and over again. Is there something I should be doing to cause a message to be removed from the Storage Queue?
1 reply
Hi, maybe a newbie question, but anyways - we experience an issue with our cluster setup caused by a partially reachable node. Our sample setup consists of 3 hosts. Seed nodes running on host 1 & 2 among some other nodes. Host 3 is running another cluster node.
SBR is set to keep-majority considering only the seed nodes.
When there is a network issue between host 1 & 3 (causing the nodes on host 1&3 to be partially reachable), the cluster actually "dies" and also nodes on host 1 are downed.
Is there a way to keep nodes on host 1 & 2 up and only downing host 3? What is the best practice for such scenarios?
SBR is set to keep-majority considering only the seed nodes.
When there is a network issue between host 1 & 3 (causing the nodes on host 1&3 to be partially reachable), the cluster actually "dies" and also nodes on host 1 are downed.
Is there a way to keep nodes on host 1 & 2 up and only downing host 3? What is the best practice for such scenarios?
Hey everyone! Today Akka (on the JVM) announced they will be changing their licensing model: https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka. Since akka.net was a port from Akka on the JVM, does this change have any kind of effect on akka.net?
@arjun-1 That's a good question, you should ask it on Discord. In the short term, it's not going to be a problem because Akka.NET still has some catch-up to do (just porting Akka Typed and newer modules could take quite some time). In the long term, that might be a different story.
Actor Cluster Slowness when Large size messages produced by a ShardRegion proxy.
We implemented Akka clustering with cluster sharding for a use case.
When we doing load testing for that, We created 1000 entity actors in a Node by cluster Sharding.(Cluster Node)
And we sends messages to that entity actors from a Proxy Node (Shard Region Proxy on other Node).
I explained in details on this question https://stackoverflow.com/questions/73795971/actor-cluster-slowness-when-large-size-messages-produced-by-a-shardregion-proxy Your valuable comments will help me so much
We implemented Akka clustering with cluster sharding for a use case.
When we doing load testing for that, We created 1000 entity actors in a Node by cluster Sharding.(Cluster Node)
And we sends messages to that entity actors from a Proxy Node (Shard Region Proxy on other Node).
I explained in details on this question https://stackoverflow.com/questions/73795971/actor-cluster-slowness-when-large-size-messages-produced-by-a-shardregion-proxy Your valuable comments will help me so much
Hey all, I qq here. I am designing a desktop app(sort of p2p system). For using a client machine to connect with other client machines we need to have port forwarding done on these machines. Any idea is the remoting module of akka.net does that automatically OR this is a manul setting users need to do manually on their routers
@Aaronontheweb (Aaron Stannard): I noticed that for the DI examples (e.g. ActorServiceProviderPropsWithScopesSpecs, ServiceProviderSetupSpecs), you used interface Xunit.IClassFixture. However, the IClassFixture's docs claim that this interface is: "Used to... indicate a test which has per-test-class fixture data". In other words, it is for sharing resources across multiple tests of a single test-class. In my case, I don't want to share the DI object across multiple tests. I need to create a fresh DI object for each test. How should I do that? Shouldn't your tests also avoid IClassFixture?
@Aaronontheweb we would like to add more sinks to the lighthouse logging. I am wondering if Serilog would be something you are open to add to the lighthouse container? Or should we fork it and do it ourselves... What do you think? I think it could be benificial to others as well....
hello guys
i have a code for stream like so
i have a code for stream like so
var transaction = Elastic.Apm.Agent.Tracer.StartTransaction("AuditNotificationActor.<StartIndexStreamMessage>", ApiConstants.TypeRequest);
try
{
if (_queue == null)
{
ActorMaterializer materializer = AuditSystemActors.Materializer;
var queueSink = Sink.Queue<IEnumerable<ESDocument>>();
var batchSink = Source.Queue<ESDocument>(100000, OverflowStrategy.Backpressure);
var flow = Flow.Create<ESDocument>().GroupedWithin(5000, TimeSpan.FromSeconds(120)).Select(s =>
{
AuditSystemActors.AuditNotificationRouter.Tell(s);
return s;
});
_queue = batchSink.Via(flow).RecoverWithRetries(attempts: 1, partialFunc: exception =>
{
Elastic.Apm.Agent.Tracer.CurrentTransaction?.CaptureException(exception);
return null;
}).To(queueSink).Run(materializer);
await _queue.WatchCompletionAsync();
}
}
catch (Exception ex)
{
Elastic.Apm.Agent.Tracer.CurrentTransaction?.CaptureException(ex);
}
finally
{
transaction?.End();
}
this will run for a while, and then suddenly stops and not pull the next set to process.
i have no clue what i am doing wrong :(
@Aaronontheweb would be awesome if can get some guidance to keep the stream running more than 20 mins :)
I'd look at whether or not you got a completion first
looks like that could be the issue
A quick question regarding sharded / event sourced actors. We have an existing code base where some sharded and event sourced actors create child actors and pass their reference when creating the children. The child then messages the parent using "parent.Tell" instead of encapsulating the message inside an envelope and sending it via the shard region actor.
I am now wondering if this could lead to some side effects (like dead letters, ...) when e.g. actors are passivated as I assume that the messages are not buffered and the actor is not reincarnated in that case?
I am now wondering if this could lead to some side effects (like dead letters, ...) when e.g. actors are passivated as I assume that the messages are not buffered and the actor is not reincarnated in that case?
@bezchristo hyperion should be used for messages on the wires, not for persistence as it isn't as versioning friendly
I tried with
.WithCustomSerializer("hyperion", new List<Type>() { typeof(System.Object) }, system => new HyperionSerializer(system, HyperionSerializerSettings.Default))
Intersting thing is: It looks like if it is set when asking:
context.GetLogger().Info(context.System.Serialization.FindSerializerForType(typeof(Object)).ToString()); hyperion is the result, however it is not listed anywhere when printing the configuration during startup.
So it seems to me the connection between new programmatic aproach and printout is broken or programmatic setup does not seem to work (in the way I'm trying it)
I think, I post this as a bug for now.
Maybe others run into this issue as well.