2016-06-18 13 views
11

ho voluto analizzare il miglioramento io veda consentendo controller asincroni in primavera avvio nel corso del controller normaleAsync Primavera Controller vs controllori normali

Così qui è il mio codice di prova. Una API restituisce un Callable e un'altra è una normale API del controller. Entrambe le API blocco per 10s simulare un'operazione lunga corsa

@RequestMapping(value="/api/1",method=RequestMethod.GET) 
    public List<String> questions() throws InterruptedException{ 
     Thread.sleep(10000); 
     return Arrays.asList("Question1","Question2"); 
    } 

    @RequestMapping(value="/api/2",method=RequestMethod.GET) 
    public Callable<List<String>> questionsAsync(){ 
     return() -> { 
      Thread.sleep(10000); 
      return Arrays.asList("Question2","Question2"); 
     }; 
    } 

a impostare tomcat incorporato con questa configurazione ovvero solo una tomcat thread di elaborazione:

server.tomcat.max-threads=1 
logging.level.org.springframework=debug 

aspettative per/api/1 Poiché esiste un solo thread tomcat, un'altra richiesta non verrà intrattenuta fino a quando non verrà elaborata dopo 10 secondi

Risultati: soddisfare le aspettative


aspettative per/api/2 Dal momento che stiamo tornando subito un callable, l'unico filo di Tomcat dovrebbe ottenere gratuitamente per elaborare un'altra richiesta. Callable avvierebbe internamente una nuova discussione. Quindi se colpisci la stessa API dovrebbe anche essere accettato.

Risultati: Ciò non sta accadendo e finché il richiamabile non viene eseguito completamente, nessuna ulteriore richiesta viene intrattenuta.

Domanda Perché/api/2 non si comporta come previsto?

+0

Tomcat esegue un threadpool, hai aspettative sbagliate. –

+0

@RomanC Ho menzionato in questione, ho impostato il threadpool del tomcat per contenere solo 1 thread. – hellojava

+0

Solo per essere sicuri: quale tipo di "altra richiesta" si invia mentre il filo della molla dorme? –

risposta

13

@DaveSyer ha ragione,/api/2 si sta comportando come previsto.

Presumo che si stia verificando il comportamento con un browser web. Almeno Firefox e Chrome stanno impedendo più richieste simultanee allo stesso URL. Se apri 2 schede con api/2, la seconda invierà una richiesta all'applicazione solo dopo aver ricevuto la risposta.

Prova provandola con un semplice script bash, come:

curl localhost/api/2 & 
curl localhost/api/2 & 
curl localhost/api/2 & 

Si stamperà 3 risposte intorno allo stesso tempo.

+0

Tu e @DaveSyer hai assolutamente ragione! Questo problema si verifica solo nel browser e non con curl o con qualsiasi strumento di test del client http. – hellojava