Suyog,
My suggestion is to move these messages to a shared library and let it be
your "executable documentation". If anyone needs to send messages to an
actor system of another team, just import the library of this team and then
you can figure out what are the actors and what case classes you can
Hi Akka hackers,
I wrote a first version of a application using Akka Actors with only Actors
fetching data from Kafka. This version works well and now I preparing a new
version using Akka Cluster to scale it.
In my application scope, process means :
1. Read data from kafka
2.
Thanks for mentioning the saga technique. To my surprise I had already used
it without knowing. That is the first thing that comes in mind in certain
situations.
But saga by no means could provide a transaction guaranties. The
intermediate state is visible to third party during so called
Yeah -- backpressure is coming into the ecosystem gradually (it is
basically the primary point of Akka Streams), but if you're doing raw
Actors you still have to manage that manually for the time being...
On Fri, Mar 10, 2017 at 2:03 PM, scala solist wrote:
> That is how
That is how I've implemented it finally. Just store messages and restore
them when the result would become clear. The actor performs some data
management, so it should have confidence in own state before it could
proceed further messages.
But reducing actor activity to just message shuffling
Hi Alexandre,
This is how the mapAsync stage works, the parallelism parameter controls
the top number of Futures/CompletionStages the stage should have processing
at once, so when the previous Future/CompletionStage completes and it's
value is emitted downstream it will immediately start the next
You must know the entity identifiers, so they must register themselves
somewhere. If those are using Akka Persistence you could use Persistence
Query to retrieve all persistence ids, which can probably be correlated to
entity ids. That is not something you would like to do for each broadcasted
>> Exactly, so you would have to have another actor (at least one) on each
node that is always alive and subscribes to pubsub and delegates to the
ShardRegion.
So no straightforward way to broadcast to all instances of an aggregate?
On Thu, Mar 9, 2017 at 10:52 PM, Patrik Nordwall
You can take a look at
https://github.com/larousso/akka-jdbc
It's experimental but you can fork and use the code as a starting point.
Le lundi 6 mars 2017 21:04:48 UTC+1, DEEPAK GUPTA a écrit :
>
> Slick available only for Scala. I need the solution for Java.
> Thanks for the reply... :)
>
Such asymmetric splits can be problematic, because the unreachability
information is spread via the gossip. E.g A2 detecting B1 to be unreachable
and that is spread to A3-B3-C3 which will start ignoring gossip messages
from B1 even though they have some connectivity. I'm not sure if that is
what
10 matches
Mail list logo