Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 03:08
    hhko commented #4094
  • Dec 13 21:37
    Aaronontheweb commented #4085
  • Dec 13 20:28
    IgorFedchenko commented #4085
  • Dec 13 20:27
    IgorFedchenko commented #4085
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb milestoned #4096
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb opened #4096
  • Dec 13 10:41
    peirens-bart opened #4095
  • Dec 13 08:37
    Aaronontheweb synchronize #4071
  • Dec 13 08:13
    jiyeongj opened #4094
  • Dec 12 15:42
    Aaronontheweb synchronize #4086
  • Dec 12 15:42
    Aaronontheweb closed #4083
  • Dec 12 15:42

    Aaronontheweb on dev

    Fix #4083 - Endpoint receive bu… (compare)

  • Dec 12 15:42
    Aaronontheweb closed #4089
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb opened #4093
  • Dec 12 14:20
    Aaronontheweb commented #4092
Gregorius Soedharmo
@Arkatufus
oh, i didn't know you can do Tell(msg, Sender)... cool, thanks
Andrew Young
@ayoung
if there are no routees available on a clustered consistent hash router, any messages that get sent just disappear. they don't even make it to the deadletters. is this the proper behavior?
Nahuel Greco
@nahuel
coming from Erlang, I want to know what are the options to run Akka.Net on Linux using F#. Can you use dotnet-core? Or you must use mono?
Bartosz Sypytkowski
@Horusiath
@ayoung could you make than as an issue on github?
@nahuel for now there are .net core builds, but they don't cover remote and cluster plugins. But you can still use mono.
Sean Farrow
@SeanFarrow
Using Akka.Persistence, when an event is successfully persisted to the backing store does the system return a success message, or is this something I need to do manually?
Corneliu
@corneliutusnea
@garrardkitchen I've started working on a WebSockets transport for Akka (v1.5). No ETA yet as I'm still learning it :)
I can't move to AWS. We are too "married" to Azure atm
Gregorius Soedharmo
@Arkatufus
with all these talk about how cheap actors are... where do you draw the line?
I mean, should I just forgo databases completely and load everything into actors? or are there cases still where database are still the smarter way to go?
Arjen Smits
@Danthar
@Arkatufus Its a tradeoff between memory usage and performance. The more you load into your actor. The more memory it consumes. If its a persistentActor that also means that it might take longer to initialise. (if you use akka.persistence there are ways to optimize by using snapshots but i digress).
That said there are ways to manage that. By using the passivate pattern to unload actors which haven't been used in a while.
Or by analysing what your 'hot' and what your 'cold' data is.
Then you can opt to more aggresively unload your 'cold' data into a database, instead of keeping them in memory inside an actor.
So there isn't one hard rule that says 'thy shall not load more then X state into your actor'
It depends on your own use-case.
Andrew Buttigieg
@andrewbuttigieg
Hi, is anyone using the Akka.Cluster.TestKit?
Looks like it is no where near as popular as Akka.TestKit...
verilocation
@verilocation

I have managed to get routing + cluster + remote deployment working fine. But I need to extend it so that my cluster also has access to a cluster.. When I do this i'm getting the following exception

Configuration missing for router [akka://Bifrost/remote/akka.tcp/Bifrost@192.168.0.121:56945/user/processor/c1/geocode] in 'akka.actor.deployment' section.

The GeocodeActor cluster is created within ProcessorActor so the path looks correct, but I'm not sure why its complaining as my config looks like this:

actor {
  provider = "Akka.Cluster.ClusterActorRefProvider, Akka.Cluster"
  ask-timeout = 30s

  deployment {
    /processor {
      router = smallest-mailbox-pool
      routees.paths = ["/user/processor"]
      nr-of-instances = 50
      cluster {
                enabled = on
                max-nr-of-instances-per-node = 50 # want less than this in production to ensure it spans multiple nodes
                allow-local-routees = off
                use-role = processor
            }
    }

    "/processor/*/geocode" {
      router = smallest-mailbox-pool
      nr-of-instances = 50
      cluster {
                enabled = on
                max-nr-of-instances-per-node = 50 # want less than this in production to ensure it spans multiple nodes
                allow-local-routees = off
                use-role = geocode
            }
    }
  }
}

Can anyone help? Thanks in advance

John Nicholas
@MrTortoise
morning. So i just noticed Receive vs Async. Does this mean that Receive is now reentrant ... The wording on async seems to imply that the async method is not re entrant.
This message was deleted
verilocation
@verilocation
I'd hazard a guess that Receive blocks the actor / current thread. ReceiveAsync won't block and will work as per standard C# async stuff which I believe is reentrant (at that particular line)
John Nicholas
@MrTortoise
Funny, i realise now ive never had to worry about this due to stashign and become. I always designed it out
The actor will be suspended until the task returned by handler completes. is the line that caught my eye in the async comment
verilocation
@verilocation
Thats probably because an Actor only processes one message at a time. And because, when you async a receive, itll not finish processing the current message even though its given up the thread temporarily
John Nicholas
@MrTortoise
ahh i see what you are getting at, sorry. yes that makes sense
verilocation
@verilocation
:)
John Nicholas
@MrTortoise
so neither of them break the akka i'm used to ;)
verilocation
@verilocation
I dont think so, but I'm not an expert :)
John Nicholas
@MrTortoise
ahh but the source is nice. I'm just about 9 months behind now
John Nicholas
@MrTortoise
@andrewbuttigieg thats probably because the non cluster testkit has been around longer combined with more people using akka core rather than clustering. Also the clustering testkit came about long after remoting so i imagine several other people figured out other ways of testing (such as starting lots of top shelf services ).
Andrew Buttigieg
@andrewbuttigieg
Yes, I am testing my work now using the regular TestKit and I think I can do most of it quite easily.
verilocation
@verilocation
Further to my question above. Am I right in thinking that the HOCON for a cluster should be on the node that creates it, rather than where it ends up? So in my case I have a cluster (processor) which then creates a cluster. (geocode) The config for the original cluster config (which works) is on the node (test client) that creates it. Should the config for the second cluster be on the same node (test client). Or the node that has the role upon which first cluster is deployed (processor)?
Andrey Leskov
@andreyleskov
Hi all, I'm debugging issue with unexpected restart of ActorSystem running in Azure WebApp. I'm using Akka.Remote actor provider. Does akka.net use same AppDomain as caller of ActorSystem.Create ? Can components of akka create own AppDomains ?
Bartosz Sypytkowski
@Horusiath
@andreyleskov actor system is just a disposable container. It doesn't know anything about app domains, so it's up to you to define, how to work with them
Andrey Leskov
@andreyleskov
so it is running in AppDomain of ActorSystem.Create caller ?
Bartosz Sypytkowski
@Horusiath
yep
Andrey Leskov
@andreyleskov
ok, thank you )
Bartosz Sypytkowski
@Horusiath
@MrTortoise actors using ReceiveAsync are not reentrant
John Nicholas
@MrTortoise
@Horusiath Thanks, i didnt think that was the case. I was wondering if it implied Receive was reenterant though, not the async one. I realise now that neither is
Bartosz Sypytkowski
@Horusiath
@verilocation you need to edit your question, you've used word cluster in few different meanings (basically none of them covers the cluster definition) and it's hard to catch the question
in case when you're creating clustered router, the config location that matters here is where you're calling ActorOf for that router.
@MrTortoise if you're using Receive + PipeTo pattern, then that actor is reentrant
verilocation
@verilocation

lol ok sorry... let me rephrase. If you look up a little youll see my initial question.

I have a test client that contains all code. It contains the HOCON mentioned above. At first it creates a ProcessActor which is defines as a clustered pool. This is remotely deployed onto a node which defines its roles as [process, geocode]. The Process actor (running on the node) then attempts to create its own clustered pool for geocodes, which just happens to be deployed to itself at the moment. Its this bit that doesnt work properly. The config for the geocode is on TestClient (I was attempting to copy how webcrawler defined this)

Bartosz Sypytkowski
@Horusiath
@verilocation not sure, if you're not overcomplicating things, but in this case you need to place geocode router config on every node, where processor actor may call it
verilocation
@verilocation

Right.. ok that works, thanks... Perhaps I am over complicating things? What would be the recommended way of doing things.

If I create a bunch of ProcessActors to process inbound messages. Would you expect them to create one actor each to work with. Or (in my case at the moment) each ProcessActor defines a pooled cluster of [geocode] to use which, I agree, is more complicated

Bartosz Sypytkowski
@Horusiath
I don't know what are your data relationships (and I'm not a big fan of routers), but maybe it would be better to have processes and geocodes as two different pools with reference to each other
verilocation
@verilocation

That sounds reasonable, how can I do that? Currently within my processor I create the geocode actor pool like so

this.GeocodeActor = ReceiveActor.Context.ActorOf(Props.Create<GeocodeActor>().WithRouter(FromConfig.Instance), "geocode");

Which (thanks to your help) I now know is taken from the node that the Processor is running on, not the test client. Would I be able to define them both in the test client but just let them know about each other?

(P.s. any reason why youre not a fan of routers?)
Bartosz Sypytkowski
@Horusiath

I don't like routers, 'cause they introduce too much "magic". If they were fully verified at compile-time, this wouldn't be much of an issue, but as everything is driven by HOCON config at runtime, it's easy to get hard to debug runtime errors.

Regarding ways to communicate:

  1. You can add some roles to cluster nodes to recognize the nodes, where process and geocode actors lives. Then on the each side, you can subscribe to something called cluster events - these are evens triggered when new node becomes visible to the current actor. With that you can filter out proces/geocode nodes and use actor selection to get references to them.
  2. Second option is to use distributed pub/sub - it's a publish subscribe mechanism that works across cluster nodes. So geocode actors simply subscribe to some topic, while process actors will publish to it.
verilocation
@verilocation
Thank you I shall look into it :)