Hi Igor,
default Glassfish V3 configuration really uses "flush" like write, so
worker thread is blocked until whole response will be written.
But it is possible to use asynchronous write [1], which solves that.
Hope this will help.
WBR,
Alexey.
[1]
http://blogs.sun.com/oleksiys/entry/glassfish_v3_asynchronous_http_responses
On Feb 2, 2009, at 18:20 , Igor Minar wrote:
> I had a brief discussion with colleagues about thread-count setting
> in glassfish.
>
> I understand that this is the max number of worker threads that
> grizzly can use, but what surprised me was that I believed that this
> wasn't the max number of concurrent connections that grizzly can
> process (concurrently send responses to). I know that the
> synchronous nature of JavaEE doesn't allow grizzly to do much magic,
> but I expected that grizzly could break the one thread per request
> paradigm for static resources.
>
> Unfortunately a simple tests with grizzly-v3-prelude and thread-
> count 5 shows that this is not true:
>
> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->>
> starts the download
> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->>
> starts the download
> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->>
> starts the download
> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->>
> starts the download
> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->>
> starts the download
> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->>
> times out!!
>
> Am I missing something? In my pet-project grizzly-sendfile[1] I was
> able to create algorithms (still experimental) which can serve
> hundreds of downloads with just a handful of worker threads. Why
> doesn't grizzly do this for static resources? The same technique
> could also be used for sending buffered JavaEE responses to slow
> clients, which should increase throughput of the server
> significantly. Ideas?
>
> /i
>
> [1] http://kenai.com/projects/grizzly-sendfile/pages/Home
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>