Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 21:29
    Aaronontheweb commented #3863
  • 21:28
    Aaronontheweb synchronize #3863
  • 21:18
    Aaronontheweb synchronize #4000
  • 21:17
    Aaronontheweb commented #3964
  • 21:17
    Aaronontheweb commented #3964
  • 21:16
    Aaronontheweb synchronize #3964
  • 21:12
    Aaronontheweb commented #3964
  • 21:08
    Aaronontheweb synchronize #71
  • 21:04
    Aaronontheweb synchronize #3973
  • 21:00
    Aaronontheweb commented #71
  • 20:58

    Aaronontheweb on dev

    Akka.Persistence.TCK fix - chec… (compare)

  • 20:58
    Aaronontheweb closed #4002
  • 20:51
    Aaronontheweb synchronize #4002
  • 20:45
    Aaronontheweb commented #3811
  • 20:45
    Aaronontheweb commented #3811
  • 20:44
    Aaronontheweb labeled #4002
  • 20:43
    Aaronontheweb milestoned #4002
  • 20:43
    Aaronontheweb opened #4002
  • 20:37
    Aaronontheweb synchronize #71
  • 20:20
    Aaronontheweb synchronize #71
Arjen Smits
@Danthar
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 :)
verilocation
@verilocation
Quick Q... we are a small team (4 developers) but we are starting to run into App.Config issues relating to public IP addresses. Is there any recommended method for dealing with different IPs in different App.Configs for different developers? Because when we check in quite often developers will check in the App.COnfig which will mess about with other developers setups as itll overwrite the IP addresses
Peter Bergman
@peter-bannerflow
Maybe IPs in the config could be avoided? What is the reason for having them there?
verilocation
@verilocation
Currently, on our dev machines, we use our public IP so that we can [a] develop independently and then [b] easily tell our lighthouses to talk to each other to check everything works in a distributed manner
Peter Bergman
@peter-bannerflow
Not sure about the setup but when I develop locally couldn't you connect to a local lighthouse as well? And just connect all nodes on loop back as hostname?
I meant when you develop locally, not I :)
Peter Bergman
@peter-bannerflow
But if you really need the IPs in there to do networked things with other developers then maybe the IP could be injected to the hocon at runtime instead.
Gregorius Soedharmo
@Arkatufus
i thought only lighthouses need predefined ip addresses, and the other nodes in the cluster find each other out through gossip?
verilocation
@verilocation
I find that if I dont specify the public hostname on all my nodes, then even though the lighthouses talk to each other and every node discovers each other, I tend to get messages like (and im paraphrasing) "Tried to send message to [public ip] but its being discard because the node is only listening on [local ip]"
But yes @Arkatufus I only make my seed / lighthouse nodes the ones that my other nodes connect to
Gregorius Soedharmo
@Arkatufus
@verilocation oh, so its a problem with nodes behind router NAT?