Multi-Reactor Pattern
781 views
Skip to first unread message
justin...@gmail.com
Aug 4, 2016, 2:19:31 AM8/4/16
to vert.x
So the Vert.x manual describes the Multi-Reactor Pattern:
So if you use Vertx on a multi core machine with several event loops, handlers which share data between one another can no longer be coded as if they were called synchronously (without volatile and locks), because they could be called by different event loops, if I understand correctly.
For example if 2 different handlers read and write to the same java.util.Map they could run concurrently because of the multiple event loops, and so the map would need to be a ConcurrentMap.
A slightly unrelated question: why are handlers always called using the same event loop?
If we've established that using multiple event loops means that handlers which interact with other handlers can't be coded as if they were synchronous, then this guarantee is no longer useful.
In fact assigning a handler to one event loop forever might cause performance issues. For example the handler for the main page of a site might be called much more than all other handlers combined and so it shouldn't be limited to 1 CPU core.
"Instead of a single event loop, each Vertx instance maintains several event loops.
Even though a Vertx instance maintains multiple event loops, any particular handler will never be executed concurrently, and in most cases (with the exception of worker verticles) will always be called using the exact same event loop."
Even though a Vertx instance maintains multiple event loops, any particular handler will never be executed concurrently, and in most cases (with the exception of worker verticles) will always be called using the exact same event loop."
So if you use Vertx on a multi core machine with several event loops, handlers which share data between one another can no longer be coded as if they were called synchronously (without volatile and locks), because they could be called by different event loops, if I understand correctly.
For example if 2 different handlers read and write to the same java.util.Map they could run concurrently because of the multiple event loops, and so the map would need to be a ConcurrentMap.
A slightly unrelated question: why are handlers always called using the same event loop?
If we've established that using multiple event loops means that handlers which interact with other handlers can't be coded as if they were synchronous, then this guarantee is no longer useful.
In fact assigning a handler to one event loop forever might cause performance issues. For example the handler for the main page of a site might be called much more than all other handlers combined and so it shouldn't be limited to 1 CPU core.
Julien Viet
Aug 5, 2016, 2:17:51 AM8/5/16
to ve...@googlegroups.com
Hi,
we provide shared data primitives in Vert.x for this case:
--
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/f0b66ed6-8939-4407-8100-fcc19f5ff738%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages