users@glassfish.java.net

Re: NIO design question

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Mon, 25 Aug 2008 18:46:53 -0400

Salut,

catching emails....

cowwoc wrote:
> Hi,
>
> I've got an NIO design question and I figured the Glassfish community
might
> know the answer because of Grizzly. If not, please suggest where I should
> ask this question.
>
> I'm looking for advice on how to implement the following architecture
in a
> scalable way. Can NIO be used for this?
>
> - My application exposes a bunch of servlets. Multiple clients invoke
those
> servlets simultaneously.
> - I want to limit the number of connections across the application (all
> servlets) and have a separate limit on the number of connections per
> specific servlet.

GlassFish supports this mechanism. Take a look at [1].


> - When a servlet is invoked, I want to push a Callable onto a worker
thread
> (which imposes the above limits) and have the servlet thread recycled
back
> into the web server without closing the underlying connection.
> - The worker thread would eventually service the client, but a single
worker
> thread would service potentially thousands of waiting clients.

If you want to do that, you need to use Grizzly Asynchronous Request
Processing. Take a look at [2] (The AsyncFilter part) for a startup.
Mainly, if you want to use two set of threads for servicing requests,
you need to tell Grizzly to not commit the response when you create your
Callable/Workerthread, and later commit the response from your second
set of commit.


>
> Why do I want to these limits? Because some servlets are very
expensive (cpu
> and memory) and are likely to cause database update collisions.


Make senses.


>
> The problem is that I don't know how to return from the servlet body
without
> closing the underlying connection. I believe the web container closes it
> automatically.

You can also take a look at the Comet technique, which is exactly what
you are looking for [3].

A+

-- Jeanfrancois


>
> Any ideas?
>
> Thanks,


[1]
http://weblogs.java.net/blog/jfarcand/archive/2007/06/improving_ajax_1.html
[2]
http://weblogs.java.net/blog/jfarcand/archive/2008/07/extending_the_g.html

[3]
http://weblogs.java.net/blog/jfarcand/archive/2006/07/the_grizzly_com.html


> Gili