playframework è veramente asincrono?

Question

Miglior risposta è nella sezione commenti (quindi non posso dare loro punti per la risposta :().

mi chiedevo se fosse play framework asincrona in questo modo (il che sarebbe veramente asincrono, o completamente asincrona) Sì, la riproduzione è asincrona sul front-end consentendo 1000 client su 100 thread, ma sul back-end, non c'è modo di ottenerlo, o sbaglio (che spero di essere) .....

public static void someRequest(String id) { 

    //This method adds listener to a nio socket listener so it returns 
    //IMMEDIATELY and page can't be rendered at this point 
    fetchRemoteDataFromOtherSystem(id, new MyListener()); 

    // DO NOT RENDER PAGE YET but return so thread can be used for other requests 
} 

public class MyListener extends SomeListener { 
    public void fireResponse(Response response) { 
     renderPage(response); 
    } 
} 

AVVISO che si tratta di un comportamento asincrono estremo e si noti inoltre che se si dispone di un sistema di back-end che impiega pochi secondi per rispondere a ciascuna richiesta, ora occorrono circa 100 macchine in meno per servire la stessa quantità di utenti. contesti normali in cui il sistema di backend è molto veloce, non ci sarebbero ovviamente differenze di prestazioni.

grazie, Dean

Answer 1

Date un'occhiata al Play 2.0. È ancora una versione beta, ma ha some nice asynchronous stuff.

Per la prima riproduzione, dare un'occhiata a this documentation page, che copre le funzioni asincrone di Play, e il (e anche se ci sei, anche Akka itself :)).

Answer 2

play 2 è totalmente asincrono da zero e utilizza akka e netty. Puoi usare il gioco sia per il tuo front end che per i servizi (es .: come riposo). Anche giocare è senza stato, quindi è molto facile scalarlo aggiungendo server.

Answer 3

Aggiungere alcuni dettagli qui. Sembra che Play abbia inventato qualcosa chiamato un oggetto Promise che estende Future e ha un modo per aggiungere un listener, quindi presumo che play aggiunga un listener sull'oggetto Promise subito dopo aver inviato la tua richiesta e quando il tuo thread di risposta chiama Promise.setResponse (xxx), quel metodo controllerà se il listener è stato ancora aggiunto e in tal caso invocherà l'ascoltatore per dire che la risposta è stata ricevuta e che il gioco lo farà uscire nella sua coda per essere processato sui suoi thread.

SE la tua risposta batte play framework aggiungendo il suo listener, quando play calls addListener, sto "assumendo" che ha codice per i controlli era la risposta già impostata sull'oggetto e, in tal caso, chiama il listener usando il thread esistente di playframeworks che scende nella coda dei playframework (o almeno spero che sia così).

Non so se è stato eseguito il porting di Promise per riprodurre 1.2.x, tuttavia, poiché l'esempio utilizzava un futuro, il gioco avrebbe dovuto eseguire il polling per vedere quando la risposta tornava ... ick .... I mi sono sempre chiesto perché non ci fosse addResponseListener su questi oggetti del futuro ... non mi è mai piaciuto.