I am trying to run an AKKA cluster on Amazon Elastic Beanstalk. A work in
progress at the moment, but I have noticed that I am suffering cluster
partitioning in various situations.
My current set up is:
Scaling group set to 4 static instances, with the potential to go up to 10
based on demand.
Hi Ketil,
It's an interesting feature. Instead of implementing an additional
replication mechanism I would replay from the journal in the active
standby. We might want to Improve the Query Side
https://github.com/akka/akka/issues/16541 first, because that will add
some replay features that might
Hi,
There are unfortunatley not any general tools that automatically draws diagrams
from actors code as far as I know. That would indeed be agreat thing to have,
but it is a bit more complicated than normal method invoking since you might
not know by static analysis which actor is the actual
Hi Eugene,
You could have the creation of actor A (and subsequently the B actors) done by
a master actor that represents a service inside the cluster, and the response
you get from that master contains a named topic or something similar where the
FSM can communicate with the A actor.
Have you
Hi Marek,
Do you want to expose a traditional blocking method call API to the clients
that internally use actors? There is no need to use typed actors for that. I
don't know the specifics of your implementation, but your blocking API could
just use ask and await the responses.
If it is
Hi Adam,
Yes, that seems to bit awkward. And yes that part of the TCP API also feels a
bit backwards. I think that we need to revisit these things when designing the
bidirectional flows that more properly represent a TCP connection in this case.
But for now I think that there is no nice
I'm currently trying to track down some very strange behavior in my actor
which is probably a race condition. What I'm basically doing is to create
actor children, use context.watch for each created child and put the
ActorRef from actorOf into a map along with other data associated with the
It means that system messages are delivered with priority over normal
messages.
Do you have a minimized reproducer of the problem you're seeing?
On Mon, Dec 15, 2014 at 5:21 PM, Stefan Podkowinski s.podkowin...@gmail.com
wrote:
I'm currently trying to track down some very strange behavior in
Hello,
Given a pool router (PR) containing 5 workers(Wn) which connect to the
database and a client actor (C) which uses and watches PR.
I would like to implement a fault tolerance strategy as follows:
1. When the database goes down, all Wn will eventually stop which will
cause PR to stop.
Same here. At first sight it looks like a bug. Any clues?
Best,
Łukasz
W dniu niedziela, 14 grudnia 2014 05:06:20 UTC+1 użytkownik Jan Ziniewicz
napisał:
Is client part of akka-http ready to use in 1.0-M1? I noticed that running
this piece of code:
Have a look at https://github.com/akka/akka/issues/16510 - it's very likely
the same bug.
On Monday, 15 December 2014 18:07:53 UTC, Łukasz Sowa wrote:
Same here. At first sight it looks like a bug. Any clues?
Best,
Łukasz
W dniu niedziela, 14 grudnia 2014 05:06:20 UTC+1 użytkownik Jan
Done, issue added: https://github.com/akka/akka/issues/16547
Adam
On Monday, December 15, 2014 12:16:17 PM UTC+1, Björn Antonsson wrote:
Hi Adam,
Yes, that seems to bit awkward. And yes that part of the TCP API also
feels a bit backwards. I think that we need to revisit these things when
Hello! Apparently as of Jersey 2.7, Java 6 is no longer supported (see
here: https://jersey.java.net/release-notes/2.7.html). If you change the
POM in the project to use Jersey 2.6 (and Java 6) the project will run --
but the tests won't work (the test container still requires Java 7).
- Paul
13 matches
Mail list logo
