Vert.x ha concurrency reale per i singoli vertici?

Question

la domanda potrebbe sembrare un troll, ma in realtà è su come vert.x gestisce la concorrenza dal momento che un vertice stesso viene eseguito in un thread dedicato. sguardo

Let a questo semplice server http vert.x scritto in Java:

import org.vertx.java.core.Handler; 
import org.vertx.java.core.http.HttpServerRequest; 
import org.vertx.java.platform.Verticle; 

public class Server extends Verticle { 
    public void start() { 
     vertx.createHttpServer().requestHandler(new Handler<HttpServerRequest>() { 
      public void handle(HttpServerRequest req) { 
       req.response().end("Hello"); 
      } 
     }).listen(8080); 
    } 
} 

Per quanto ho capito la documentazione, tutto questo file rappresenta un verticle. Quindi il metodo di avvio è chiamato all'interno del thread dedicato del verticle, finora tutto bene. Ma dov'è la richiesta di Handler? Se è invocato su esattamente questo thread non riesco a vedere dove è meglio di node.js.

Sono abbastanza familiare con Netty, che è la libreria di rete/concorrenza su cui vert.x è basata. Ogni connessione in entrata viene mappata su un thread dedicato che si adatta in modo soddisfacente. Quindi ... questo significa che le connessioni in ingresso rappresentano anche i vertici? Ma come può quindi l'istanza verticle "Server" comunicare con quei client? In realtà direi che questo concetto è limitato come Node.js.

Per favore aiutami a capire bene i concetti!

saluti, Chris

Answer 1

ho parlato a qualcuno che è molto coinvolto in vert.x e mi ha detto che io sono fondamentalmente proprio sulla questione "concorrenza".

MA: Mi ha mostrato una sezione dei documenti che mi mancava totalmente dove "Scaling server" è spiegato in dettaglio.

Il concetto di base è che quando si scrive un vertice si ha solo prestazioni single core. Ma è possibile avviare la piattaforma vert.x usando il parametro -instance che definisce il numero di istanze di un dato vertice. Vert.x fa un po 'di magia sotto il cofano in modo che 10 istanze del mio server non provino ad aprire 10 socket del server ma in realtà una singola invece. In questo modo vert.x è scalabile orizzontalmente anche per singoli vertici.

Questo è davvero un grande concetto e soprattutto un ottimo quadro !!

Answer 2

Ogni vertice è a thread singolo, all'avvio il sottosistema vertx assegna un ciclo di eventi a quel vertice. Ogni codice in quel vertice verrà eseguito in quel ciclo di eventi. La prossima volta che dovresti fare domande nel http://groups.google.com/forum/#!forum/vertx, il gruppo è molto vivace e molto probabilmente la tua domanda verrà immediatamente risposta.

Answer 3

Come hai correttamente risposto a te stesso, il vertice utilizza effettivamente la programmazione asincrona non bloccante (come node.js) in modo da non poter eseguire operazioni di blocco perché altrimenti si fermerebbe l'intero mondo (applicazione).

È possibile ridimensionare i server come indicato correttamente, generando più istanze di vertice (n = core CPU), ognuna cercando di ascoltare sulla stessa porta TCP/HTTP.

perché faccia luce rispetto a node.js è che la JVM in sé è multi-threaded, che vi dà più vantaggi (dal punto di vista di runtime, non compresa la sicurezza di tipo Java etc etc):

• La comunicazione multithreading (cross-verticle), pur essendo vincolata a un modello simile ad Actor thread-safe, non richiede IPC (Inter Process Communication) per passare messaggi tra i vertici - tutto avviene all'interno dello stesso processo, stessa regione di memoria. Quale è più veloce del nodo.js deposizione delle uova ogni compito biforcuta in un nuovo processo di sistema e l'utilizzo di IPC per comunicare
• Capacità di fare compute-pesanti e/o bloccare le attività all'interno dello stesso processo JVM: http://vertx.io/docs/vertx-core/java/#blocking_code o http://vertx.io/docs/vertx-core/java/#worker_verticles
• Velocità di JVM HotSpot rispetto al V8 :)