Dado que es compatible con Servlet 3.0 asynchronous processing. ¿Sería mejor utilizar siempre el procesamiento asíncrono? ¿O en qué casos es mejor el procesamiento sincrónico?Servlets asincrónicos vs servlets síncronos
Lo importante que obtiene con los servlets asíncronos es HTTP push, donde el servidor puede devolver información al cliente cuando lo desea, en lugar de cuando el cliente lo solicita. Servlets previos al asincronización, esto requeriría conexiones HTTP de larga ejecución que ataban cada una de las cadenas de servidores, lo que es muy ineficiente. Este nuevo modelo desacopla el procesamiento del lado del servidor del manejo de la conexión.
El procesamiento asíncrono se ha introducido para los casos en que no hay necesidad de mantener un hilo durante todo el ciclo de procesamiento de solicitudes. El ejemplo típico de tal caso es una funcionalidad similar a comet.
El uso del procesamiento asincrónico en todos los casos no valdrá nada, ya que generalmente el procesamiento de fondo consume un hilo de todos modos.
Al leer el artículo, el soporte de procesamiento asíncrono en la especificación Servlet 3.0 tiene un caso de uso muy específico: está diseñado para manejar el caso donde tiene una aplicación AJAX que realiza solicitudes que desencadenan procesos potencialmente de larga duración en segundo plano.
El motivo por el que necesitábamos algo como esto fue para responder a un problema en el modelo de subproceso por solicitud, que asigna un subproceso cada vez que el cliente solicita una página del servidor, en lugar de asignar un solo subproceso para el cliente toda la sesión Esto funcionó bien antes de AJAX cuando los clientes realizaban solicitudes esporádicamente, pero los beneficios se perdían cuando las aplicaciones AJAX aumentaban significativamente el número de solicitudes que un cliente haría.
Específicamente, si una solicitud AJAX desencadena algo potencialmente lento o bloqueante, como una operación de base de datos, estamos de vuelta donde comenzamos: los hilos del grupo de hilos del servidor están potencialmente inactivos.
El soporte de procesamiento asincrónico intenta mitigar esto al colocar las solicitudes en una cola centralizada, de modo que los subprocesos no siempre están bloqueados esperando los resultados de las solicitudes que aún no se han comenzado a procesar. En resumen, estamos tratando de aprovechar al máximo nuestro dinero en nuestros hilos en todo momento, es decir, disminuyendo la cantidad de tiempo cuando están inactivos (pero podrían servir para otra conexión).
Como cualquier novedad, esto no es algo que deba usarse como una herramienta única para todos. Busque el caso específico en su aplicación donde sea apropiado.
+1 "Leer el artículo ..." – user359996
Acabo de leer el artículo vinculado, esto es una mejora del lado del servidor, no asincrónica del lado del cliente.
Resumiendo el artículo:
Usted quiere usar servlets asincrónicos en una situación en la que usted tiene una carga de peticiones que entran (similar a golpear su servidor con peticiones AJAX), y no quiere servir hasta un hilo por solicitud. TPR puede ser peligroso en este escenario cuando el tiempo de procesamiento demora un poco, lo que hace que agote su grupo de subprocesos.
El trabajo se quedará atascado en una cola de trabajos y el hilo se puede retirar hasta que el trabajo finalice y la respuesta finalmente se confirma cuando los recursos se liberan para permitir que se complete.
Bastante genial.
Su base a requrirement donde cualquier posibilidad de un hilo se interponen en estado de reposo en esa situación u debe utilizar asíncrono servlet de otro modo no pd de que no puede hacer tantos hilo
Si un servlet o un filtro alcanza un potencial operación de bloqueo al procesar una solicitud, puede asignar la operación a un contexto de ejecución asíncrono y devolver el hilo asociado con la solicitud de inmediato al contenedor sin generar una respuesta. La operación de bloqueo se completa en el contexto de ejecución asincrónico en un hilo diferente, que puede generar una respuesta o enviar la solicitud a otro servlet.
para habilitar el procesamiento asíncrono en un servlet, establecer el parámetro asyncSupported en true en la anotación @WebServlet como sigue:
@WebServlet (urlpatterns = { "/ asyncservlet"}, asyncSupported = true) AsyncServlet clase pública extiende HttpServlet {...}
Sincrónico (Modelo de aplicación web clásico) Una solicitud síncrona bloquea el cliente hasta que finaliza la operación, es decir, el navegador no deja de responder. En tal caso, el motor de script java del navegador está bloqueado.
Asincrónico (modelo de aplicación web AJAX) Una solicitud asíncrona no bloquea el cliente, es decir, el navegador responde. En ese momento, el usuario puede realizar otras operaciones también. En tal caso, el motor de script java del navegador no está bloqueado.
En comunicación sincrónica ambos son activos al mismo tiempo mientras que en asíncrona no hay necesidad de activos al mismo tiempo por ejemplo asíncrono se refiere a la mensajería hay bloqueo de operación para un nuevo hilo y ejecutar el subproceso asociado al recipiente
Los contenedores web en servidores de aplicaciones normalmente usan un hilo de servidor por solicitud del cliente. En condiciones de carga pesada, los contenedores necesitan una gran cantidad de hilos para atender todas las solicitudes de los clientes. Las limitaciones de escalabilidad incluyen quedarse sin memoria o agotar el conjunto de subprocesos de contenedor. Para crear aplicaciones web escalables, debe asegurarse de que ningún subproceso asociado con una solicitud esté inactivo, por lo que el contenedor puede usarlas para procesar nuevas solicitudes.
Existen dos escenarios comunes en los que un hilo asociado a una solicitud puede estar inactivo.
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.
+1 para obtener un resumen claro. – BalusC
¿Qué sucede si está revisando los datos de AJAX en el lado del servidor y el usuario va a una página web diferente? Entonces, ¿ya no necesitan esa información? ¿O qué sucede si el usuario actualiza la página? ¿Habría ahora dos instancias en el lado del servidor que verificaran esos datos del usuario? – gmustudent