Asynchrone Servlets vs. synchrone Servlets

Question

Seit Servlet 3.0 asynchronous processing wird unterstützt. Wäre es besser, immer asynchrone Verarbeitung zu verwenden? Oder in welchen Fällen ist die synchrone Verarbeitung besser?

Answer 1

Das große Ding, das Sie mit asynchronen Servlets bekommen, ist HTTP push, wo der Server Informationen zurück zum Klienten feuern kann, wenn es wählt, anstatt wenn der Klient danach fragt. Pre-Asynch-Servlets, dies würde lange laufende HTTP-Verbindungen erfordern, die jeweils einen Server-Thread binden, was sehr ineffizient ist. Dieses neue Modell entkoppelt die serverseitige Verarbeitung von der Verbindungsbehandlung.

Answer 2

Asynchrone Verarbeitung wurde für die Fälle eingeführt, in denen während des gesamten Anforderungsverarbeitungszyklus kein Thread gehalten werden muss. Das typische Beispiel für einen solchen Fall ist eine ähnliche Funktionalität.

Die Verwendung der asynchronen Verarbeitung in allen Fällen würde nichts wert sein, da die Back-End-Verarbeitung normalerweise sowieso einen Thread verbraucht.

Answer 3

Lesen Sie den Artikel, asynchrone Verarbeitungsunterstützung in der Servlet 3.0-Spezifikation hat einen sehr spezifischen Anwendungsfall - es wurde entwickelt, um den Fall zu behandeln, in dem Sie eine AJAX-Anwendung haben, die potenziell lange laufende Prozesse im Hintergrund auslöst. Der Grund, warum wir so etwas brauchten, bestand darin, auf ein Problem im Thread-pro-Anfrage-Modell zu reagieren, das jedes Mal einen Thread zuweist, wenn der Client eine Seite vom Server anfordert, anstatt einen einzelnen Thread für den Client zuzuordnen ganze Sitzung. Dies funktionierte vor AJAX gut, wenn Clients sporadisch Anfragen stellten, aber die Vorteile gingen verloren, wenn AJAX-Anwendungen die Anzahl der Anforderungen eines Clients signifikant erhöhten.

Insbesondere, wenn eine AJAX-Anfrage eine potenziell langsame oder blockierende Datenbank wie eine Datenbankoperation auslöst, sind wir wieder da, wo wir angefangen haben - Threads aus dem Threadpool des Servers sind möglicherweise inaktiv.

Die Unterstützung für asynchrone Verarbeitung versucht dies zu verringern, indem Anforderungen in eine zentrale Warteschlange gestellt werden, sodass Threads nicht immer auf Ergebnisse von Anforderungen warten müssen, die möglicherweise noch nicht verarbeitet wurden. Kurz gesagt, wir versuchen zu jeder Zeit den meisten Knall aus unseren Threads herauszuholen - das heißt, die Zeit zu verringern, wenn sie im Leerlauf sind (könnte aber eine andere Verbindung bedienen).

Wie bei jeder neuen Entwicklung, ist dies kein universelles Werkzeug. Suchen Sie in Ihrer Bewerbung nach dem konkreten Fall, in dem es angebracht ist.

Answer 4

Ich habe gerade über den verlinkten Artikel überflogen, dies ist eine serverseitige Verbesserung, nicht clientseitig asynchron.

Fasst den Artikel:

Sie wollen würde Asynchronous Servlets in einer Situation verwenden, wo Sie eine Last von Anfragen haben kommen in (ähnlich dem Server mit AJAX-Anforderungen zu Bashing), und Sie wollen nicht dienen einen Thread pro Anfrage hoch. TPR kann in diesem Szenario gefährlich sein, wenn die Verarbeitungszeit etwas dauert und Sie Ihren Thread-Pool ausschöpfen.

Der Job wird in einer Jobwarteschlange hängen bleiben, und der Thread kann zurückgezogen werden, bis der Job abgeschlossen ist und die Antwort endgültig festgeschrieben wird, wenn die Ressourcen freigegeben sind, damit sie abgeschlossen werden kann.

Ziemlich coole Sachen.

Answer 5

Sein auf requrirement basiert, wo alle Chancen ein Thread zu dieser Situation im Ruhezustand erhalten u Asynchrone Servlets beacause wir sonst nicht so viele Fäden

machen kann keine potenziell Wenn ein Servlet oder ein Filter erreicht verwenden sollte blocking operation beim Verarbeiten einer Anfrage, kann sie die Operation einem asynchronen Ausführungskontext zuordnen und den der Anfrage zugeordneten Thread sofort an den Container zurückgeben, ohne eine Antwort zu erzeugen. Die Blockierungsoperation wird im asynchronen Ausführungskontext in einem anderen Thread abgeschlossen, der eine Antwort generieren oder die Anforderung an ein anderes Servlet senden kann.

Um asynchrone Verarbeitung auf einem Servlet zu ermöglichen, die Parameter auf wahr auf der @WebServlet Annotation asyncSupported wie folgt:

@WebServlet (urlpatterns = { "/ asyncservlet"}, asyncSupported = true) public class AsyncServlet extends HttpServlet {...}

Synchron (klassisches Webanwendungsmodell) Eine synchrone Anforderung blockiert den Client, bis der Vorgang abgeschlossen ist, dh der Browser reagiert nicht mehr. In diesem Fall wird die Java-Script-Engine des Browsers blockiert.

Asynchron (AJAX-Webanwendungsmodell) Eine asynchrone Anforderung blockiert den Client nicht, d. H. Der Browser reagiert nicht. Zu dieser Zeit kann der Benutzer auch andere Operationen ausführen. In diesem Fall ist Java Script Engine des Browsers nicht blockiert.

In synchroner Kommunikation beide aktiv sind, zur gleichen Zeit, wo, wie in Asynchronous keine Notwendigkeit, aktiv zur gleichen Zeit beispielsweise Asynchronous dort an den Messaging bezieht sich auf einen neuen Thread Betrieb blockiert und den Betrieb den Faden mit dem Behälter zuzugeordneten

Webcontainer in Anwendungsservern verwenden normalerweise einen Serverthread pro Clientanforderung. Unter hohen Lastbedingungen benötigen Container eine große Menge an Threads, um alle Kundenanforderungen zu erfüllen. Skalierbarkeitsbeschränkungen umfassen, dass nicht genügend Arbeitsspeicher zur Verfügung steht oder der Pool von Container-Threads erschöpft ist. Um skalierbare Webanwendungen zu erstellen, müssen Sie sicherstellen, dass keine mit einer Anforderung verknüpften Threads inaktiv sind, sodass der Container sie zum Verarbeiten neuer Anforderungen verwenden kann.

Es gibt zwei häufige Szenarien, in denen ein mit einer Anfrage verbundener Thread im Leerlauf sein kann.

The thread needs to wait for a resource to become available or process data before building the response. For example, an application may need to query a database or access data from a remote web service before generating the response. 

The thread needs to wait for an event before generating the response. For example, an application may have to wait for a JMS message, new information from another client, or new data available in a queue before generating the response.