I use per-request actors. The only ask() is in the route, and is sent to a
RequestHandler actor. The RequestHandler creates a per-request actor with
the sender as a Props/Constructor parameter ("requestor"), and sends it a
"Run" message.
The per-request actor can coordinate with as many actors as
A very interesting read and I appreciate you showing examples. What I do
wonder about there is what the situation is when the server has to do more
than simply return information from a database or other similar web rest-ui
simple examples. For example, I have processes that require aggregating
I'm still curious what, if any, advantages the ProducerStage as in
reactive-kafka has over using mapAsync as in CassandraSink. Anyone?
On Fri, Mar 31, 2017 at 7:40 AM, Richard Rodseth wrote:
> I was looking at the implementation of the reactive-kafka ProducerStage.
> Very
persistAll is used, meaning that the state change event and the other
events are sent in one message to the journal. akka-persistence-cassandra
will write them in a batch. I don't think there is any/much overhead of
using separate events.
In general with event sourcing, it's good to have separate
The configuration for the Cassandra plugin is in need of refactoring, but
currently you have to do as I described here:
https://github.com/akka/akka-persistence-cassandra/issues/81#issuecomment-292545442
/Patrik
On Thu, Apr 6, 2017 at 6:09 AM, Richard Ney wrote:
> Has
I have an akka-stream project, in which I'd like to detect bottle-neck
stages, to try and optimize them.
I was thinking that it could be useful to use an analogy between streams
and electrical currents, to see which parts are more resistive.
Electrical intensity can be easily understood as the