Frank1962
22-01-2010, 01:33
Alur ...da un pò è uscito il Glassfish 3 con pieno supporto alle Servlet v3 che alcuni di voi sapranno finalmente introducono il concetto di Async ....quà un pò di codice, quello della servlet che usa l'async:
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.concurrent.ScheduledThreadPoolExecutor;
import javax.servlet.AsyncContext;
@WebServlet(urlPatterns = "/AsynchServlet", asyncSupported = true)
public class AsynchServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
AsyncContext aCtx = request.startAsync(request, response);
ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(10);
executor.execute(new AsynchRunnable(aCtx));
}
}
Questa è la servlet con supporto dell'asincrono abilitato ...adesso passiamo a definire la classe AsynchRunnable, cioè il thread che farà il lavoro "oneroso" in termini temporali:
import javax.servlet.AsyncContext;
public class AsynchRunnable implements Runnable {
AsyncContext ctx;
public AsynchRunnable(AsyncContext ctx) {
this.ctx = ctx;
}
public void run() {
// Simulate a long-running task such as
// calling a webservice, performing database
// operation, or waiting for a server side
// event (such as receiving a message in
// Comet-enabled environment.
try {
// Sleep for 1000 ms
Thread.sleep(1000);
} catch (Exception ie) {
}
ctx.dispatch("/response.jsp");
}
}
ecco come vedete l'ultima classe è quella che simula il lavoro "sporco" ....vedendo questo codice di esempio di queste nuove funzionalità mi è sovvenuto un dubbio alquanto fastidioso: ma non è che stà async è solo lato client? ....cioè nel senso che, come in questo caso, se mi arrivano 10 richieste dal client di svolgere altrettanti AsynchRunnable mi ritroverò con l'executor che sarà obbligato ad istanziare altri nuovi thread per svolgere eventuali ulteriori richieste :( ....e se invece, per esempio, invece del Thread.sleep ci fosse una lettura dell'InputStream del client che mi invia i dati molto lentamente ......non è che vado a sprecare Thread inutilmente dato che svolgono lavori dove potrebbero in realtà essere riciclati invece di attendere sulle read bloccanti che l'interfaccia della classe ServletInputStream mi offre? ...ma perchè non hanno implementato i canali anche con le Servlet? che ne so ...una ServletChannel? :confused:
Oppure sono io che mi sbaglio è c'è qualche modo che mi permette di utilizzare un pool fisso di thread senza che qualcuno di questi rimanga bloccato su una read() o write() da e per il client?
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.concurrent.ScheduledThreadPoolExecutor;
import javax.servlet.AsyncContext;
@WebServlet(urlPatterns = "/AsynchServlet", asyncSupported = true)
public class AsynchServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
AsyncContext aCtx = request.startAsync(request, response);
ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(10);
executor.execute(new AsynchRunnable(aCtx));
}
}
Questa è la servlet con supporto dell'asincrono abilitato ...adesso passiamo a definire la classe AsynchRunnable, cioè il thread che farà il lavoro "oneroso" in termini temporali:
import javax.servlet.AsyncContext;
public class AsynchRunnable implements Runnable {
AsyncContext ctx;
public AsynchRunnable(AsyncContext ctx) {
this.ctx = ctx;
}
public void run() {
// Simulate a long-running task such as
// calling a webservice, performing database
// operation, or waiting for a server side
// event (such as receiving a message in
// Comet-enabled environment.
try {
// Sleep for 1000 ms
Thread.sleep(1000);
} catch (Exception ie) {
}
ctx.dispatch("/response.jsp");
}
}
ecco come vedete l'ultima classe è quella che simula il lavoro "sporco" ....vedendo questo codice di esempio di queste nuove funzionalità mi è sovvenuto un dubbio alquanto fastidioso: ma non è che stà async è solo lato client? ....cioè nel senso che, come in questo caso, se mi arrivano 10 richieste dal client di svolgere altrettanti AsynchRunnable mi ritroverò con l'executor che sarà obbligato ad istanziare altri nuovi thread per svolgere eventuali ulteriori richieste :( ....e se invece, per esempio, invece del Thread.sleep ci fosse una lettura dell'InputStream del client che mi invia i dati molto lentamente ......non è che vado a sprecare Thread inutilmente dato che svolgono lavori dove potrebbero in realtà essere riciclati invece di attendere sulle read bloccanti che l'interfaccia della classe ServletInputStream mi offre? ...ma perchè non hanno implementato i canali anche con le Servlet? che ne so ...una ServletChannel? :confused:
Oppure sono io che mi sbaglio è c'è qualche modo che mi permette di utilizzare un pool fisso di thread senza che qualcuno di questi rimanga bloccato su una read() o write() da e per il client?