Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 07:55
    ismaelhamed commented #3284
  • Sep 13 16:35
    Aaronontheweb commented #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3914
  • Sep 13 16:34
    Aaronontheweb commented #3914
  • Sep 13 01:50
    Aaronontheweb synchronize #3914
  • Sep 13 01:45
    Aaronontheweb commented #3914
  • Sep 12 14:10
    Aaronontheweb synchronize #3914
  • Sep 12 14:10

    Aaronontheweb on dev

    name AzureDevops artifacts per … (compare)

  • Sep 12 14:10
    Aaronontheweb closed #3915
  • Sep 12 13:57
    Aaronontheweb synchronize #3915
  • Sep 12 13:37
    Aaronontheweb opened #3915
  • Sep 12 06:43
    Horusiath commented #3628
  • Sep 12 05:57
    Horusiath synchronize #3628
  • Sep 12 02:05
    Aaronontheweb synchronize #3901
  • Sep 12 02:04
    Aaronontheweb commented #3914
  • Sep 12 02:03
    Aaronontheweb synchronize #3914
  • Sep 12 01:11
    Aaronontheweb commented #3105
  • Sep 12 01:10
    Aaronontheweb closed #3105
Aaron Stannard
@Aaronontheweb
just methods / functions?
Tomasz Jaskula
@tjaskula
let say I have something I want to use on PreRestart for every actor
like writing to some DB log or something
Aaron Stannard
@Aaronontheweb
ah
every one of those actors
should be given their own instance of that object
part of the goal of the actor model
is to avoid locking / shared state concurrency
the other thing you can do
if you don't want every actor to have to hold onto a DB connection
is to create a single type of actor who's job it is to write stuff to the DB
and give everyone else a reference to an instance of that actor type
Tomasz Jaskula
@tjaskula
thanks @Aaronontheweb
Aaron Stannard
@Aaronontheweb
@JaspritBola hmm... after downing a node it should be removed
and no further attempts should be made to contact it
if it's not getting removed then that's a bug
I'll take a look at that
Tomasz Jaskula
@tjaskula
@Aaronontheweb this means than in F# passing the same function around is the same issue. I have to use a reference to an actor or embed behavior in a class and pass instances
Aaron Stannard
@Aaronontheweb
I'm not an F# expert but that sounds right
Bart de Boer
@boekabart
@Aaronontheweb the acceptable heartbeat pause does the trick, as in, it delays the disassociation to 60 seconds now. It happens only and always when the system is under load (ingesting a file, leading to 100k's of messages through the ActorSystem). these peaks can and do last up to 60 or more seconds, during which, apparently, not a single heartbeat makes it back and forst. The comms themselves work, since the 'work' command (1 single message) comes from the remote. The work being done is parallel enough to keep my 4 cores busy for a while. But in a way it's strange that not a single one heartbeat makes it through, right?
qwoz
@qwoz

if I want an actor to send a message to all its children, is this the best way to do it?

Context.ActorSelection("*").Tell(message);

or is there a better way?

Aaron Stannard
@Aaronontheweb
Context.GetChildren()
then iterate over the list
qwoz
@qwoz
is that not the same under the hood? Or is ActorSelection not preferred as it consumes CPU evaluating the expression?
Aaron Stannard
@Aaronontheweb
But in a way it's strange that not a single one heartbeat makes it through, right?
100% CPU utilization is a bitch
starts to become difficult to keep any promises at that rate
with the newer transport and some of the other changes we're making
Akka.Remote should be more performant
and require less CPU / memory for even better throughput
1.1 will make some big improvements there
1.5 will be even bigger
@qwoz they're different
ActorSelection gets resolved "outside" the actor
Context.GetChildren() is done in-memory, locally
it's a much faster lookup
and doesn't allocate anything
other than a iterator
qwoz
@qwoz
ok, fair enough... might be nice to have something like that as a convenience method, along the lines of: Context.Children.Tell(message), but I can live with a couple extra lines of code to iterate over it.
Alex Koshelev
@akoshelev
Hi guys. Are you planning to fix #1700 before akka.cluster goes out of beta?
Bart de Boer
@boekabart
@Aaronontheweb now I've done a try to limit the # of main threadpool threads to # cores (4). What happens now is that on all 4 threads, the code is 'waiting' for a queue to produce smth, and this queue is fed by a pair of actors running on a dedicated ThreadPool dispatcher.
(code needs to get a unique id non-async, and we've implemented that using a 'client' and (shared/could-be-remote) 'server' actor, both of which are on that dedicated threadpool)
now, I still get a deadlock, all threadpool threads hung on that Akka.dll!Helios.Concurrency.DedicatedThreadPool.UnfairSemaphore.Wait . Including Remote, by the way
Bart de Boer
@boekabart
so all 4 akka.remote TPthreads and my 2 dedicted TPthreads all hung on that, because the others are basically very slow (a lot of messages to process, taking 1 second each because that's the timeout for retrieving such an ID from the concurrentQueue.
I've seen this come loose, which I suppose happens after the dispatcher is done with it's batch, but what are those other threads syncing with the main TPthreads for!?
(there's an assumption there)
Bart de Boer
@boekabart
... please forget anything I said above... I use persistence in one of these actors, and persistence still runs on the default dispatcher.
Bart de Boer
@boekabart
Still 'deadlocks' but I suspect that's because Sqlite plugin somewhere does something on the threadpool too
Bart de Boer
@boekabart
Read the thing over and over, still can't figure out how to change the default dispatcher in Hocon. Help!
it's not akka.actor.default-dispatcher = my-dispatcher (nullReferenceException)
Bart de Boer
@boekabart
is the only way akka.actor.deployment{"/*"{ dispatcher = my-dispatcher }} ?