Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 21 15:57
    Aaronontheweb closed #3877
  • Oct 21 15:57
    Aaronontheweb commented #3877
  • Oct 21 15:56

    Aaronontheweb on dev

    Persistence TestKit documentati… (compare)

  • Oct 21 15:56
    Aaronontheweb closed #3889
  • Oct 21 07:27
    dependabot-preview[bot] labeled #3999
  • Oct 21 07:27

    dependabot-preview[bot] on nuget

    Bump FluentAssertions from 4.14… (compare)

  • Oct 21 07:27
    dependabot-preview[bot] opened #3999
  • Oct 20 17:25
    valdisz synchronize #3889
  • Oct 20 17:17
    valdisz synchronize #3889
  • Oct 20 15:44
    valdisz synchronize #3889
  • Oct 20 09:22
    ismaelhamed commented #3863
  • Oct 19 23:39
    valdisz synchronize #3889
  • Oct 19 23:08
    edvinasz commented #2947
  • Oct 19 13:36
    Aaronontheweb commented #3973
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3995
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump BenchmarkDotNet from 0.10.… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] edited #3995
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3993
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump Google.Protobuf from 3.9.1… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3991
Aaron Stannard
@Aaronontheweb
and you can still have a high degree of parallelism
Tomasz Jaskula
@tjaskula
I meat rather using for example a common portion of code
like for example you write it once and then you use it for several actors
Aaron Stannard
@Aaronontheweb
oh
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.