The reason grizzly is scalable is that it uses NIO, which means that one
thread can handle requests from many clients. But for the duration of a
request, the thread is only servicing that particular client.
So say you have a pool of 10 threads -- a servlet request comes in and
is assigned to a particular thread, leaving 9 in the pool. That thread
executes the servlet (or whatever) for the client, which is typically a
short operation. When the doGet /doPost method is finished, the thread
returns to the pool, where it will wait for another request. In this
manner, the pool of threads can handle 10 simultaneous requests from
tens of thousands of users. [Compare that to tomcat, which requires a
single thread for each client, and hence can handle only as many clients
as it can create threads.]
For JSF, this isn't really any different -- the request comes in, and
the FacesContext is created and stored in the ThreadLocal. As the
short-lived JSF request is executed, the thread can access the JSF data
in the threadlocal. When the request is completed, the FacesContext is
destroyed and the thread is returned to the pool.
-Scott
On Thu, 2006-11-02 at 20:03, roger.keays wrote:
> Hi there,
>
> I read on Jean Francois' blog how grizzly allows glassfish to run with as
> few as 10 threads and be quite scalable. I'd like to know how this works
> with JSF, since AFAICT, JSF uses a single-thread-per-request model as it
> relies on the FacesContext which is stored as a ThreadLocal. Is that true?
> If so, wouldn't that mean you still need a whole stack of threads for JSF
> apps?
>
> Thanks,
>
> Roger
> --
> View this message in context: http://www.nabble.com/threads%2C-grizzly-and-jsf-tf2565079.html#a7149746
> Sent from the java.net - glassfish users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>