Is it OK create a thousands Verticles like Actors in Akka?

[Alexander Dederer]

Good day!

In my current Project (MMO, Server-Side) I need a fast framework for handle thousands connection per sec and massive async Game Data Model changes.
So. because I have a concurrent actions to modifying a single object instance i have two way to prevent collisions:
1. Use locking. But it's a not an ease because i need lock a many objects before modification. and it has performance issue
2. Create many Verticles per each game object. So only one Verticle will handle all modifications own object and no locking required

My question: is it OK solution for Vertx? Create a lot Verticles (one per game object = about 200k Verticle) like an Actors in Akka or I need another way?

[Jochen Mader]

Wrong analogy :)

An Actor in Akka would be a Handler in Vert.x.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/020aaad9-a4f5-4559-bf8a-e4b4e0816d15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Lead IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

[javadevmtl]

Verticles should be about 2xcores max. But you can register as many handlers/ consumers on the event depending on how much memeory you can afford. So you can have a handlefull of registration verticles and each "game" object can request the regsitration verticle to create a handler with a unique address.

[Alexander Dederer]

Thanks for answer!

Ok. Verticle is just only a "starter" for registering Handlers.
It's means I need still lock data structures before calculation/modification.
All i can do it's just split Game world to different zones. Each zone = own Verticle (assign to the one Thread).
This Zone owner Verticle registered Handlers for each Games objects on this Zone.

And all modification action in this zone will be synchronized (because all Handlers from single Verticle will work in the same Thread). No locking required.

Main problem what I need to do when Game object will interact from one Zone to another :)

Thanks to all!


четверг, 11 мая 2017 г., 14:32:09 UTC+3 пользователь Jochen Mader написал:

Wrong analogy :)

An Actor in Akka would be a Handler in Vert.x.

2017-05-11 13:07 GMT+02:00 Alexander Dederer <alex.d...@gmail.com>:

Good day!

In my current Project (MMO, Server-Side) I need a fast framework for handle thousands connection per sec and massive async Game Data Model changes.
So. because I have a concurrent actions to modifying a single object instance i have two way to prevent collisions:
1. Use locking. But it's a not an ease because i need lock a many objects before modification. and it has performance issue
2. Create many Verticles per each game object. So only one Verticle will handle all modifications own object and no locking required

My question: is it OK solution for Vertx? Create a lot Verticles (one per game object = about 200k Verticle) like an Actors in Akka or I need another way?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/020aaad9-a4f5-4559-bf8a-e4b4e0816d15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mumuney Abdlquadri]

"Main problem what I need to do when Game object will interact from one Zone to another :) "

I don't think that would be a problem. There are several means of communication between Verticles. One is the EventBus.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/c4646e72-3233-4c79-8161-a5a3b6d189db%40googlegroups.com.

[Alexander Dederer]

Problem in modifications Game state. We must modify different object in the same time as a atomic/transactional modification and while modification proceed we must not read a dirty data from any object used in modification action. Eventbus not help with this. They used for another purpose :)

All i need it's a in-memory object oriented transactional safe DB with high performance. It's out of scope Vertx solution.



четверг, 11 мая 2017 г., 16:16:28 UTC+3 пользователь Mumuney Abdlquadri написал:

[ad...@cs.miami.edu]

>>Problem in modifications Game state. We must modify different object in the same time as a atomic/transactional modification and while modification proceed we must not read a dirty data.

>>All i need it's a in-memory object oriented transactional safe DB with high performance.

Sounds like you simply need an in memory data structure that is properly synchronized to not expose dirty data.  This is pretty straight forward to do in traditional Java style.  The problem is that during data access the structure will block other threads (event loops) accessing the structure. But, it will work.  On the other hand, I really would not consider quick synchonized access to be real "blocking" (like IO or heave CPU).  To implement this, I would use the singleton pattern to create a single shared instance across all verticles.

-Adam

[Alexander Dederer]

I think I can use Verticle per Game Zone as a singletone for games object in this Zone. In this case all operations inside Zone will be atomic, transactional and do in one Thread. No locking required.

When action required interact 2 and more Game Zone than I need:
* lock local object
* do modification
* send modification in message to another Verticle (to another Game Zone)
* unlock local object


четверг, 11 мая 2017 г., 18:05:58 UTC+3 пользователь ad...@cs.miami.edu написал:

[ad...@cs.miami.edu]

>> Verticles should be about 2xcores max.

I am not sure I agree that Verticles should be 2x core max?   Perhaps there should be 2xCore event loop threads, but I think there could be lots of Verticles.  Multiple verticles can share the same event loop thread, so long as there is no blocking.  Of course, more pressure on the thread will affect performance, but I don't see that it would be a problem in theory or practice.  Thoughts?

-Adam

[Tim Fox]

On Thursday, 11 May 2017 18:18:40 UTC+1, ad...@cs.miami.edu wrote:

>> Verticles should be about 2xcores max.

I am not sure I agree that Verticles should be 2x core max?   Perhaps there should be 2xCore event loop threads, but I think there could be lots of Verticles. 

Agreed. Have *at least* 2 * cores verticles so you can scale across cores but you can have many more than that. A Java verticle is just a Java object instance plus some associated objects (note that non Java, e.g. JS, Ruby verticle instances can have much more overhead due to the language engines)