Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 08:29
    ismaelhamed commented #5066
  • 08:02
    Zetanova commented #5083
  • Jun 11 19:31
    Arkatufus synchronize #5089
  • Jun 11 19:31
    Arkatufus synchronize #5089
  • Jun 11 15:20
    Arkatufus synchronize #5089
  • Jun 11 15:20
    Arkatufus synchronize #5089
  • Jun 11 12:48
    Arkatufus synchronize #5089
  • Jun 10 21:30
    Arkatufus synchronize #5089
  • Jun 10 19:20
    Arkatufus labeled #5089
  • Jun 10 19:20
    Arkatufus opened #5089
  • Jun 10 19:07
    Arkatufus converted_to_draft #5088
  • Jun 10 15:46
    Arkatufus opened #5088
  • Jun 10 15:46
    christallire commented #5066
  • Jun 10 14:43
    Aaronontheweb commented #5086
  • Jun 10 14:35
    wesselkranenborg commented #5086
  • Jun 10 14:29

    Arkatufus on dev

    Return `T` from `IDependencyRes… (compare)

  • Jun 10 14:29
    Arkatufus closed #5087
  • Jun 10 14:29
    Arkatufus closed #5086
  • Jun 10 10:18
    evenbrenden closed #5083
  • Jun 10 10:18
    evenbrenden commented #5083
Aaron Stannard
@Aaronontheweb
doing some performance golf on Akka.Actor primitives today: akkadotnet/akka.net#5030
Jake Zhang
@Kiddinglife
Hey I am wondering if it is liekly to have different trasnport implementations for the actors? for example, some actors uses udp protocol and some other use tcp. I kenw this can be easily done by running two actor systems with udp and tcp transport repectively. but can we do the same thing when it comes with an single actor system ? thank you.
Aaron Stannard
@Aaronontheweb
@Kiddinglife yep, you can - Akka.Remote supports having multiple transports enabled. You can pick and choose which transport you use to communicate based on the protocol found inside the ActorPath
1 reply
James World
@james-world

I have a question about logging. I see there's been a bit of work done to integrate with .NET Core's DI's system, and the IHostedService model. I've seen there are some integrations with logging solutions like Serilog and Log4Net that have been around a while. These libraries themselves now have good integrations with .NET Core's logging abstraction.

.NET Core's logging abstraction (ILogger<T> etc) now has a number of nice features (structured logging, support for e2e tracing, context etc.). I prefer using the core framework abstractions when possible since it makes integrating cross-cutting concerns across libraries much easier, its easier to grok for new hires etc.

To that end:

(1) Is it bad to inject ILogger<T> using DI rather than using Akka.Net's logging system? I guess I would miss out on some Akka system logging, and that it might have other issues?

(2) Has anyone tried creating a LoggingAdapter integration with ILogger<T>? Whilst I'm not an expert, scanning through the Serilog adapter it doesn't look like it would be a ton of code and I'm surprised no-one has done it. I'm wondering if there are some non-obvious challenges?

Any advice much appreciated.

Aaron Stannard
@Aaronontheweb
(1) Is it bad to inject ILogger<T> using DI rather than using Akka.Net's logging system? I guess I would miss out on some Akka system logging, and that it might have other issues?
yes
from a performance point of view, you can end up creating a global lock that syncs all actors together when you use the ILogger<T>
i.e. if it's writing to a file stream
we've seen people do that with Serilog too, for the record
we should probably create a logging plugin that just takes the ILogger and uses that inside a dedicated logging actor, like what we do with serilog: https://github.com/akkadotnet/Akka.Logger.Serilog
(2) Has anyone tried creating a LoggingAdapter integration with ILogger<T>? Whilst I'm not an expert, scanning through the Serilog adapter it doesn't look like it would be a ton of code and I'm surprised no-one has done it. I'm wondering if there are some non-obvious challenges?
no but we should do that
similar to how we have the Setup for working with IServiceProvider
we should add one for working with ILogger
IMHO
James World
@james-world

OK, good to know - thanks for the detailed response @Aaronontheweb . I would have thought any sane file logger sink would be fed from a queue (like the ConsoleLoggerProcessor that's used for the ConsoleLogger - but I see there's no MS file logger provided, so I guess that's a mistake others have made. I can see how an actor effectively does that for you.

The project I'm working on at the moment is using Serilog is most places - which I may stick with anyway given the current investment. Just evaluating options at the moment. There are certainly some inconveniences with the way Microsoft.Extensions.Logging handles structured logging - you pretty much have to either put every named property you want in the log message or jump through some major hoops : dotnet/runtime#35995. Serilog handles this much better.

If we do decide to do an ILogger<T> implementation I'm sure we can contribute it.

Leon Mwazange
@leomwa__twitter
image.png
Hi.
Does this mean I will have (1) 5 routers and (2) a total of 200 routees in each node?
Im trying to come up with an IoT device scenerio where there are routers and I want about 200 devices per node.
3 replies
Brah McDude
@brah-mcdude

I am creating my props like so:

Props.Create<MyActor>().WithDispatcher(CallingThreadDispatcher.Id)

When I debug, I see that the Context.Dispatcher.Id is null. Is this normal?

image.png

9 replies
Vagif Abilov
@object
We have an Akka.NET cluster running in a set of Windows VMs (with onging work to migrate it to Kubernetes). Are there any caveats with adding to it additional nodes that run in Kubernetes, i.e having a hybrid cluster consisting of some nodes running on Windows VMs and others running Linux in K8?
Sean Farrow
@SeanFarrow
Is it possible to dynamically configure the stages of a stream using say some form of file base configuration? I’ve got a case where a stream needs to take in piece of data and then fanout to multiple destinations based on the client configuration that can be dynamically updated. What will be the best way of handling this?
Aaron Stannard
@Aaronontheweb
@SeanFarrow the Hub types in Akka.Streams are the way to go
PartitionHub or BroadcastHub
you can dynamically attach consumers to it
without having to recompile everything upstream

We have an Akka.NET cluster running in a set of Windows VMs (with onging work to migrate it to Kubernetes). Are there any caveats with adding to it additional nodes that run in Kubernetes, i.e having a hybrid cluster consisting of some nodes running on Windows VMs and others running Linux in K8?

not AFAIK - as long as everything is reachable over the same subnet you should be fine

if you're running in Azure that should be doable by just having your AKS cluster and Azure VMs running in the same subnet
and you might need to have the CNI networking enabled on your pods - where they acquire a real IP from the subnet in Azure versus using the Kubernetes control plane to get a virtual IP
Sean Farrow
@SeanFarrow
@Aaronontheweb thanks, now all I need to do is work out how to represent the graph in some form of configuration file. Has anyone done anything like this that you know of?
Aaron Stannard
@Aaronontheweb
not that I know of - although it should be possible for everything except Bidi flows to represent that via file @SeanFarrow
since they're all directed asyclic graphs otherwise
Aaron Stannard
@Aaronontheweb
Akka.NET v1.4.21 release notes just dropped - take a look at the performance numbers: akkadotnet/akka.net#5071
Tom May
@tjdecke

Akka.NET v1.4.21 release notes just dropped - take a look at the performance numbers: akkadotnet/akka.net#5071

Great work, thank you!

Aaron Stannard
@Aaronontheweb
@/all Akka.NET v1.4.21-beta1 is now live on NuGet as a pre-release package. We have created a discussion thread on the main Github repo to gather feedback from users: https://github.com/akkadotnet/akka.net/discussions/5073 - if all goes well we will turn Akka.NET v1.4.21 into a full release by the end of next week. But we need your feedback to help make that happen! See the full details of what's included here: https://github.com/akkadotnet/akka.net/releases/tag/1.4.21-beta1
Aaron Stannard
@Aaronontheweb
Don't forget that we have our Akka.NET Community Standup in ~2 days (June 9th, 1:30pm CST)
whoops, wrong link
David Montgomery
@dmontgomery
I'm trying to work through a data migration project from a legacy system, and I think the Streams API is probably what I should be using. Ideally, I'd have an actor reading from the legacy database in smallish chunks repeatedly, and publish/broadcast those chunks to downstream actors which would translate/push the data into the new database. Is there a sample out there of such a database Source?
David Mercer
@dbmercer

Is this a usual pattern to pass an actor ref to an actor:

public class TaskScheduler : ReceiveActor
{
    public TaskScheduler( IActorRef poller ) { }

    public Props Props( IActorRef poller )
    {
        return Akka.Actor.Props.Create( () => new TaskScheduler<TTask>( poller ) );
    }
}

?

Both of these actors are being created in a supervisor actor's PreStartà la:

protected override void PreStart()
{
    var poller = Context.ActorOf( TaskPoller.Props() );
    var scheduler = Context.ActorOf( TaskScheduler.Props( poller ) );
}

Is that a usual pattern for this sort of thing?

Ismael Hamed
@ismaelhamed
@dbmercer yes. You can also pass the IActorRef in a message too.
1 reply
Vagif Abilov
@object

We have changed cluster seed-nodes specification to use fully qualified domain name, and now nodes can't form a cluster.
Before:
akka.tcp://MyCluster@maodatest01:1963 (works fine)
After:
akka.tcp://MyCluster@maodatest01.XXX.com:1963 (doesn't work)

Isn't both specifications equivalent?

Aaron Stannard
@Aaronontheweb
@object I think I addressed this in your issue but I suspect there's a DNS issue at work there
left some ideas for how to debug that
Akka.NET Community Standup coming in 45 minutes https://www.youtube.com/watch?v=nWPZIfSi2uE
Calven Yow
@CalvenYow_twitter
Hi,
Calven Yow
@CalvenYow_twitter
What is the deployment strategy in Kubernetes is preferred for deploying cluster sharding system? Deployment or StatefulSet kind? Currently I'm using statefulset kind, however during the rolling deployment, I could see the shards are handover to the old instance first and wait for the new instance is deployed and rebalance the shards again. Is there a way to handover the shards to the new instance directly without going through the old instance and wait for rebalance?
David Mercer
@dbmercer
Is it OK to process a message in an async void method that is called with Receive instead of ReceiveAsync so long as you don't touch shared state after the await? Basically, I'm doing an await and then a Self.Tell, which seems pretty much equivalent to using PipeTo, right?
Ismael Hamed
@ismaelhamed
@dbmercer no, if you try to access the context after an await you should get an "There is no active ActorContext" exception, since Akka does not preserve the context in this case. Use the PipeTo instead, it is there to prevent you from using all these anti-patterns you mentioned.