ActorRef has a self type of ActorRefImpl. This means that if I want to
fake/stub/mock an ActorRef for test purposes, I cannot because I am forced
to know about ActorRefImpl. Instead of users of ActorRef being forced to
only use the ActorRefImpl implementation, ActorRef should be a minimal
Hi,
We've been using Persistent FSMs for a while now, and really like them -
the combination of the structure and functional state with event sourcing
is really useful for us in many cases.
However, there are some places where the API feels a bit strange, or that
it's missing some things, and
Thanks for the answer Konrad
On Monday, August 14, 2017 at 8:15:19 PM UTC-7, Konrad Malawski wrote:
>
> There has not been much interest in that from what I can cell.
> Rather people are using k8s, marathon/mesos etc to run Akka applications
> nowadays.
>
> —
> Konrad `kto.so` Malawski
> Akka
On Wed, Aug 16, 2017 at 1:28 PM, Igor Baltiyskiy wrote:
> Hello Patrik,
>
> thanks for the reply. Could you please clarify a few points:
>
> 1. How are Replicators tied to node roles?
>
Replicator.props takes ReplicatorSettings, which contains a role property.
> Can I start
You can use Cluster Sharding and DData with roles. So, let's say that you
go with 10 roles, 10,000 entities in each role. You would then start
Replicators on the nodes with corresponding nodes. You would also start
Sharding on the nodes with corresponding roles. On a node that doesn't have
the a
Hi Yannik,
if your logging facility were capable of streaming then you could also avoid
the double materialization issue using the .alsoTo combinator: you send the
bytes to the logger while processing them in your business logic. This is also
beneficial if the logger compacts the data,
Thanks for confirming. It's just that with the way you said it on the
ticket, calling the usage of toStrict a "workaround", you made it sound
like even if toStrict was in the API, all its uses were kind of wrong and
workarounds for a "proper" and "streaming" way to consume the entity body
more
After some thought, I could instead do "master-master" replication, because
in the cache, each entry is versioned, and newer versions always trump
older ones --- kind of a LWWRegistryMap with versions for timestamps. In
that scenario, I'd have several actors for each entity, and each of them