I don't know if this answers your question but this is what I did:
I just used a normal specs2 test with TestKit
In order to test full cycle I used
com.github.michaelpisula %% akka-persistence-inmemory %
0.1-SNAPSHOT % test
which requires
akka.persistence.journal.plugin =
Hi,
On Mon, Apr 28, 2014 at 3:13 PM, faisal.daj...@gmail.com wrote:
Hello,
I was reading about remoting, and there's something I can't quite figure
out. From what I managed to understand, the idea is that I can specify an
actor to be assigned to a specific host, and have it always run
Hi Matthias,
On Tue, Apr 29, 2014 at 8:38 PM, Matthias Heininger
muenchn...@googlemail.com wrote:
Hi Endre,
Thanks for your reply.
The weird thing is the fact that a String works as message.
Can you give me a hint where to look for the internationalization
configuration or how to figure
Hi Erich,
As Tim pointed out, one way is to use an in-memory journal and use the
ordinary akka TestKit. To simulate failures you may use the Kill message (
http://doc.akka.io/docs/akka/2.3.2/scala/actors.html#Killing_an_Actor) that
will force the actor to throw an ActorKilledException. It might
Thanks, that looks useful.
I'm using spray.client at the moment to make the network call (to a
web-service). I'm not sure how the akka.io stuff would fit in to this
though?
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Hi James,
Spray sits on top of akka.io. Unfortunately I don't think you can modify
how it talks to the Tcp connection. Anyway, since akka-http will use
reactive streams this batching behavior will be used by default. I am not
sure how much it will buy though, spray is already pretty fast.
-Endre
*Hi*
*I do work on a project where it is required to spawn new actors during
runtime. Their implementation details as well as their configuration may be
unknown during system startup as their code is deployed on-demand.*
*As we use custom mailboxes to hook our actors up with the data sources,
Hi Christian,
On Wed, Apr 30, 2014 at 11:49 AM, Christian Kreutzfeldt mnx...@gmail.comwrote:
*Hi*
*I do work on a project where it is required to spawn new actors during
runtime. Their implementation details as well as their configuration may be
unknown during system startup as their code
Hi Christian,
30 apr 2014 kl. 12:10 skrev Christian Kreutzfeldt mnx...@gmail.com:
Update: I just figured out how to implement the described behavior without a
mailbox but connecting directly with a source (eg. Kafka topic) and poll data
on regular base using self-issued timeout messages.
Awesome, a quick glance through the cluster documentation shows that it
might be what I was looking for. Many thanks for the response and link.
On Wednesday, 30 April 2014 11:03:52 UTC+3, Akka Team wrote:
Hi,
On Mon, Apr 28, 2014 at 3:13 PM, faisal...@gmail.com javascript:wrote:
Hello,
We have a full example as part of the akka persistence mongo journal here:
https://github.com/ddevore/akka-persistence-mongo/tree/master/akka-persistence-mongo-command-sourcing-example-app
Note: This is command sourcing only and we are about to do a full sample
with event sourcing and views.
Am Mittwoch, 30. April 2014 12:08:23 UTC+2 schrieb Akka Team:
Hi Christian,
On Wed, Apr 30, 2014 at 11:49 AM, Christian Kreutzfeldt
mnx...@gmail.comjavascript:
wrote:
*Hi*
*I do work on a project where it is required to spawn new actors during
runtime. Their implementation details
I have a cluster singleton that I use with ClusterSingletonProxy and it
works really well. I am trying to find out, if its possible to reply to
messages from ClusterSingleton. When I try to reply to messages in the
singleton, the messages always end up in the node where the singleton is
Thanks Tim, I'd kinda started down the (2) route.
On Wednesday, April 30, 2014 10:32:23 AM UTC-4, Tim Pigden wrote:
Possible options might be:
1. register listeners on your eventsourcedProcessor and send them the
events.
2. use an eventbus to publish the events (saves mucking around
Hello!
I'm not sure if it's possible at all, but if there's a FSM actor A, which
is in state S1, then it receives a message M, which triggers a transition
to state S2, and in onTransation the actor A sends some messages to another
actor B. The actor B process message and sends reply R to
Hello Eugene,
The scenario you have outlined can not happen - you’re safe from this kind of
race thanks to the Actor’s properties.
The transition as well as calling the transition handlers for the new state are
all still happening during Actor A’s receive, which means that it is guaranteed
Hi,
I have an play application running on an ubuntu instance. Application uses
akka actor system. Is there a way to open the typesafe console for
monitoring the actors on unix system?
Thanks,
Arvind
--
Read the docs: http://akka.io/docs/
Check the FAQ:
17 matches
Mail list logo