2015-03-02 13 views
9

Dopo aver letto sul connettore NIO Tomcat, non riesco ancora a ottenere una cosa: il connettore nio è utile se il codice dell'applicazione sta bloccando, ovvero si blocca durante la lettura dal database, nella lettura del file system, sulla chiamata di servizi Web esterni?Connettore NIO Tomcat con un'applicazione di blocco

Quindi, ad esempio, si dispone di un'API simile a REST che riceve una richiesta, legge qualcosa dal database e restituisce una risposta. Non usa il servlet 3 async, scrive solo sulla risposta.

Non ho trovato una descrizione completa dei pool di thread utilizzati dal connettore NIO, ma immagino che abbia un pool di thread per la gestione delle richieste, quindi ogni richiesta finisce nel proprio thread, che può bloccare.

In questo caso, i vantaggi di NIO sono ancora presenti o il codice di blocco diminuisce i vantaggi di NIO (in termini di utilizzo delle risorse)?

+0

correlati http://techblog.bozho.net/why-non-blocking/ – Bozho

risposta

9

Il connettore nio è utile se il codice dell'applicazione sta bloccando ...?

, il connettore NIO è costruito con il presupposto che la vostra applicazione si blocca da qualche parte. Il connettore NIO ha fondamentalmente diversi segnaposto per socket e risponde alle nuove richieste in arrivo fino a quando le informazioni non iniziano a essere riscritte.

non ho trovato una descrizione completa dei pool di thread utilizzati dal connettore di NIO

Credo che questo sia l'inizio della vostra confusione. Tomcat NIO ha un pool di selettori, non un pool di thread (reference). Il codice connettore esegue il polling di ogni selettore per verificare se ha byte in entrata o in uscita da inviare. In questo senso, il selettore di una determinata richiesta continuerà a ricevere informazioni finché non vi è abbastanza per elaborare la richiesta con un oggetto Richiesta/Risposta che colma il divario tra I/O sincrono e I/O asincrono (reference).

Il codice di polling non blocca mai più del tempo necessario per serializzare un pacchetto di informazioni, quindi è libero di gestire nuove richieste. L'unica vera limitazione è la quantità di memoria disponibile per Tomcat. Mentre esiste un pool di thread, il numero di thread effettivamente utilizzati è molto inferiore al numero di connessioni che l'applicazione può gestire (reference).

Mentre ci sono differenze di prestazioni tra i connettori Tomcat (reference), la differenza nel tempo di richiesta/risposta non elaborati è piuttosto ridotta quando il servlet stesso si blocca. Tuttavia, la differenza nel numero di richieste simultanee che Tomcat può gestire è molto diversa quando si utilizza l'I/O non bloccante.

+3

Quindi, cosa succede in questo caso con ThreadLocal? Se il socket è simulato e lo stesso thread è condiviso tra più richieste, può creare una mancata corrispondenza quando si usa ThreadLocal. Ma in realtà questo non succede. In che modo Tomcat (e probabilmente altri contenitori) risolve questo problema? – AlexR

+0

Grazie. Oltre alla domanda di @AlexR - nella pagina che hai linkato c'è "maxThreads" - max thread dove? Quindi c'è una piscina? – Bozho

+0

http://stackoverflow.com/questions/7925014/is-threadlocal-safe-to-use-with-tomcat-nio-connector – Bozho

Problemi correlati