Thanks Patrik, this worked. For me I know that 3 members should join, so
I was able to do this like
TestKit.awaitCond(
cluster1.state.members.size ==3cluster2.state.members.size
==3driverCluster.state.members.size ==3,
20seconds
)
Still though my test takes 11 secs to run due to some
Hi all. I'm using Akka Streams 1.0-RC3, and am getting some weird behavior
with a custom FlexiRoute. I'll post the code below, but the behavior I'm
seeing is that when this FlowGraph is run, I only see one or two outputs in
the log, and then nothing more. I can't figure out why the stream isn't
Oops, forgot to post the
link: https://www.parleys.com/tutorial/easy-scalability-akka (you'll need
to register a free account to view the full video).
On Friday, June 19, 2015 at 4:36:05 PM UTC-7, Luis Medina wrote:
I just saw this really interesting presentation from Scala Days that
I just saw this really interesting presentation from Scala Days that
Martynas posted in another thread that talks about scaling with Akka. I
think it will give you some ideas for how to design your app in a way that
scales even if you are starting out small right now.
On Thursday, June 18,
Nice. I was wondering when this would start happening as people see Akka
HTTP as a way to dev webapps more directly without Play. I too recently
converted a showcase (at https://github.com/cretz/scala-web-ideal) that has
a few of the same type of helpers (but not near as many). I think there
as people see Akka HTTP as a way to dev webapps more directly without Play
Yep. To be honest, I do not understand why I would need Play for website
development at all now. akka-http is more lightweight and flexible than
Play and it has much better routers than play's ones. The main problem now
is
Thank you Luis.
On Jun 20, 2015 4:06 AM, Luis Medina lu4...@gmail.com wrote:
Oops, forgot to post the link:
https://www.parleys.com/tutorial/easy-scalability-akka (you'll need to
register a free account to view the full video).
On Friday, June 19, 2015 at 4:36:05 PM UTC-7, Luis Medina wrote:
Try ExecutionContext (for Futures) and/or FlowMaterializer (for marshalling).
See
https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L51
I am writing an application where I have different types of entities. I
wrote a generic DAO object with Slick to perform basic CRUD operations, and
I want to create routes to make a simples http service for these entities.
I have similar routes, so I wanted to write a function for a generic
We have been using the following approach with success:
Each cluster-member writes/updates an alive-record to the database each
X-seconds.
It also checks how many other alive nodes are found in the database.. (I
know this solution does not scale massively)
If number of alive nodes in database is
Hi Peter,
We exactly want this, we want to hand it off this to an actor and handle
the response asynchronously. What did you do about this problem?
On Thursday, January 8, 2015 at 4:37:58 PM UTC+5:30, Peter wrote:
Hello,
I'm playing arround with the Java-API of the new akka-http server and I
I'd recommend you to look at Akka Persistence. You can store entitiy as
PersistentActor, and collect statistics by corresponding PersistentView.
Also, you can employ Cluster Sharding and use passivation to remove
inactive entities from RAM.
On Thursday, June 18, 2015 at 12:57:30 PM UTC+5,
You can activate an actor if not present, as long as you send the message
to its supervisor, so you have to keep say, supervisors per zone? and each
supervisor will try to send/forward the message to such child and if not
present create it.
This is an example in Java where I do the same thing
I think It's not enough. There are events which will happen when the user
is not logged in. For example an attack on a village (which its owner is
inactive) or occupation of that village also generates a message to the
owner player actor (which is not resident) as well. So I can't activate
Thanks Patrik. I'll look into it.
On Wednesday, 17 June 2015 17:51:56 UTC+5:30, Patrik Nordwall wrote:
I would guess that you are filling up the tcp buffer, and then Akka will
back-off and start buffering the messages. Maybe you can see this log
message:
log.warning([{}]
These technologies and architectures are so appealing to me but I'm
still in doubt
whether I should follow these interesting approaches or just make a
traditional software (with a monolithic database-driven model).
Although this is a side project, it's very
I completely agree with you. Thanks again :)
On 06/19/2015 06:47 PM, Guido Medina
wrote:
Trust me you don't want to do concurrency by
yourself even if you are an expert at it, asynchronous design is
the way to go, with Akka that concern is
Say you don't have zones or any sort of grouping, you need at least one
supervisor, I wouldn't recommend you to make all your players top level
actors where their parent is /user, you need a fast way to locate a
player and context().child(...) is such way IMHO, sharding with persistent
actor
Trust me you don't want to do concurrency by yourself even if you are an
expert at it, asynchronous design is the way to go, with Akka that concern
is easy enough and you will be able to focus only on the business logic and
produce results, the last thing I'm going to Advice you is to not
Nvm, that would run into the same problem, instead, eagerly load the
player's zone -a supervisor for a bunch of players- and then lazily load
the player per zone, that will keep your actors distributed and also will
prepare your code to use these zones as shards when the game grows.
On Friday,
If your number of shards is high enough and your hashcode is smart enough
coalitions should be very minimal, I think you should have stats of how
many players you have per shard and how busy shards get, and between
restarts *-maintenance time-*, redo your numbers and hashcode formulas,
And don't worry about performance, assuming each shard has a pattern of
Single Consumer - Multiple Producer, make sure the inbox type for shards
and players is SingleConsumerOnlyMailbox which is a the fastest Akka
mailbox atm.
On Friday, June 19, 2015 at 1:43:46 PM UTC+1, Guido Medina wrote:
There you go:
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/routing-dsl/testkit.html
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
50K is like zero for current and modern hardware, so, I would say, load
them lazily from your players' supervisor and don't expire them until you
start seeing a problem, expiring them would require you only to set context
time out at preStart() and then handle the timeout message which would be
Another option, if you don't have player ID but a sort of ID as string,
say, attach player oxygen8, get the hash of that string and apply the
same formula, so you have 64 shards, so the supervisor of that player is
oxygen8.hashCode() % 64
On Friday, June 19, 2015 at 1:01:00 PM UTC+1, Guido
Hi,
how can I run unit tests for my web services?
I found in MC2 there's an undocumented TestKit:
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/http/index-testkit.html
But in RC3 it's not listed:
You're absolutely right. I need at least one supervisor (or maybe
two; one for players and one for villages as they are top level
actors). This way I can deactivate and lazy load them as you said.
And yes I don't have millions of players :D but I hope some day I'll
You could even have the concept of lazily load the zone and each zone
lazily load the players.
On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote:
50K is like zero for current and modern hardware, so, I would say, load
them lazily from your players' supervisor and don't expire
Yes it would be very nice. But I have no idea how to find a player
zone. Suppose player A want to attack player B. First we need to
find out the player B zone (to find it's supervisor). Right? Then we
need an actor which knows about the players zone. That would be the
Do you have player IDs? design your application to have zones divided by a
number -preferably a power of 2-, say, 64, now you have 64 evenly
distributed shards so to send a message to player ID = 1001 then you just
need to 1001 mod shards, no look up needed, it is just a convention you are
Great community project once HTTP 1.1 support is final and shipped.
On Thu, 18 Jun 2015 at 21:51 Roland Kuhn goo...@rkuhn.info wrote:
Not short-term: first we must support HTTP/1.1, then we can think about
the next steps.
Regards,
Roland
18 jun 2015 kl. 21:18 skrev Heiko Seeberger
Thanks Guido, this is good idea but as I'm not going to make this
game distributed (at least in the near future) I feel this approach
increases the complexity and I don't know what would I get instead
of this complexity? (except for RAM usage optimization)
The
Hi,
I just checked some code on 2.3-dev branch:
https://github.com/akka/akka/blob/release-2.3-dev/akka-http-marshallers-java/akka-http-jackson/src/main/scala/akka/http/javadsl/marshallers/jackson/Jackson.scala
Greetings,
Is there a DynamoDB snapshot plugin for akka-persistence available
anywhere? There is not one listed on the community page and my searches
have been fruitless. If not, is this because of technical limitations with
DynamoDB or simply because one hasn't been created yet?
Thank you,
Personally, I wouldn't organize your actors into zones since zones aren't
really a concept that would exist in your game and like you pointed out, it
can make scaling a bit tricky. The approach that I would take is to use
clustering along with sharding to distribute your actors across however
Hi Bill,
I don't see a reason why such implementation wouldn't make sense - in fact
many of the other NoSQL stores nowadays are very dynamo inspired :-)
So I'd say it's just a matter of actually sitting down and implementing it.
PS: We're in the middle of the final adjustment phase in Akka
You are right Guido, I never used Akka in production though I have
implemented several successful applications with Scala, Play and
ReactiveMongo. And there is a single server with 50K user at
maximum. Certainly, supporting more users and advanced scenarios
would be
Hi, all!
Soon after I had started three different projects with akka-http I realized
that I copy-pasted too often. Things like login directive, session tokens,
PJAX, password encryption were shared. In fact, they seem to be common for
many akka-http projects.
So, I've made akka-http-extensions
38 matches
Mail list logo
