We found that ClusterSystem-scheduler-1 thread is very busy and consume
50% cpu (but not more than 50%).
And we meet 'node unreachable' issue every day.
Here's our configs:
akka.cluster {
failure-detector {
acceptable-heartbeat-pause = 6 s # default 3 s
threshold = 12.0#
Hello Ashey,
I guess you answered your question(s) yourself:
- in-between receiving Passivate and Terminated the Manager will buffer all
incoming messages for the passivating Aggregate
- when receiving Terminated it will flush the buffer for the Aggregate,
which can result in activation again.
Can you send us a stack trace of the scheduler thread?
On Tue, Jul 15, 2014 at 7:45 AM, Xingrun CHEN cowboy...@gmail.com wrote:
We found that ClusterSystem-scheduler-1 thread is very busy and consume
50% cpu (but not more than 50%).
And we meet 'node unreachable' issue every day.
Here's our
We have about 100k actors who sent heartbeat to client side evey several
seconds. (use system.scheduler.scheduleOnce)
And we found it may cause the cluster heartbeat delay. So we change the
config `akka.cluster. scheduler.tick-duration` to 9 ms, and then the akka
cluster created a second
Hello,
I was wondering whether there is any performance implication in case one
sets the maximum frame size to a ridiculously large size.
In my case, I may have some large files exchange. So, if I set e.g.
max-frame-size to 200MiB instead of the rather-low default one, should I
expect any
To make it more clear: will there be any performance degradation for small
messages (couple of kilobytes)?
On Tuesday, July 15, 2014 11:54:41 AM UTC+2, Asterios Katsifodimos wrote:
Hello,
I was wondering whether there is any performance implication in case one
sets the maximum frame size
Hello Asterios,
It’s not a very good idea to use actor messaging to send such huge messages
using akka’s remote messaging.
Reason being - you’ll delay other messages until the huge one has been pumped
through the network.
Actor messages should ideally be in kilobyte ranges.
1) In your case I
Hi Konrad, thanks for the suggestions! I will soon impement a blob service
(yes, we have HDFS in our environment - that's a good choice).
But my question remains unanswered: does the maximum-frame-size, if set
ridiculously high, play any role in the performance of small (couple of
kilobytes),
Yes it will degrade, because you’ll clog the connection between system `A` and
`B` while pumping through LargeMessage,
and the other waiting SmallMessages won’t get through while the large one is
being written.
--
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io
--
Read the
Hello John,
Just store the confirmations too:
case c @ Confirmation(deliveryId) =
persist(c) { _ = confirmDelivery(deliveryId) }
I also recommend watching our ScalaDays talk (Patrik at the 3/4 mark speaks
about the AtLeastOnceDelivery trait):
Hi John,
When using the PersistentActorWithAtLeastOnceDelivery you have to persist
everything yourself. You call the persist method for each event you want
replayed after the actor restarts. For at least once delivery you should at
least persist the event that will be used in deliver as well
Completely glazed over that section of docs.
Thanks!
On Tuesday, July 15, 2014 8:40:27 AM UTC-4, Michael Pisula wrote:
Hi John,
When using the PersistentActorWithAtLeastOnceDelivery you have to persist
everything yourself. You call the persist method for each event you want
replayed
Hello Alexandre,
First things first: There *must not* be multiple persistent actors in the
system with the same persistentId.
There must be exactly one persistent actor writing to the journal using a
given persistent id.
Otherwise we can't guarantee any ordering. I mean you can start 2 separate
Just like Michael (quoting Patrik) said :-)
Also, please note that Passivate is *not *a feature of akka-persistence,
it's a feature of cluster sharding:
http://doc.akka.io/docs/akka/2.3.4/contrib/cluster-sharding.html
It's true however that it (and the entire cluster sharding) plays very well
Hi,
I revised my implementation and done with
https://gist.github.com/whiter4bbit/22cd3b0909bb390e80db. For my particular
case there is relatively long window between requests, in many cases
Appends and Removes count will match (also possible by calling
confirmDelivery for messages, that not
Dear Akka Leads and Team,
Direct Fn is a software solution provider for financial industry,
specializing in market data and trading back ends, last year we started a
project call Direct Fn Integration platform in order to integrate systems
for B2B services and Real Time Business Intelligence.
Hello,
I would like to understand what happens to the yet undelivered queued
messages that were sent by an actor that was just terminated.
For example, actor A send message M to B. M is queued as B is currently
occupied. A is terminated. Will the message M be delivery to B? If so, is
there a
I think this is a fantastic development (if I understand it correctly).
From my reading and basic understanding I had concerns about the need for
two event infrastructures to 1) implement more complex view models in CQRS
because currently Views can't follow more than one PersistentActor, and
18 matches
Mail list logo
