Hi William,
it's a good question, and unfortunately what you suspect is right - in
Grizzly 1.x response output stream writes are blocking, that's why we
had to introduce all that ConcurrentCometHandlers etc,
and need synchronization to avoid multiple threads writing on the same
connection.
For Grizzly 2.0 this would be fixed, we're currently working on the
Comet module, but frankly saying we want to keep it because of
backwards compatibility.
Otherwise I'd probably recommend use Grizzly 2.0 HttpServer directly,
where you can suspend/resume HTTP request processing and even have NIO
input/output streams support, which might be useful [1]. Unlike in
Comet (where you have this out-of-the-box), in HttpServer you'll need
to maintain the registered client collection in your own code and also
implement simple event broadcast mechanism.
WBR,
Alexey.
[1]
http://java.net/projects/grizzly/sources/svn/content/branches/2dot0/code/samples/http-server-samples/src/main/java/org/glassfish/grizzly/samples/httpserver/nonblockinghandler/NonBlockingHttpHandlerSample.java
> I work on a Comet based application and I use grizzly comet support
> in order
> to send notification to registered users. We don't use long polling
> but
> streaming because we send a lot of data to the users.
>
> We still used a old version of grizzly (packaged in glassfish 2.1.1)
> but we
> plan to upgrade to a standalone grizzly server with the latest
> version. But
> my question does not depend on the grizzly version, I think....
>
> From my understanding, grizlly use the NIO framework in order to not
> block
> threads. In addition, on comet side, there is a thread pool used to
> send
> event in a non blocking manner.
>
> During some load test, I have seen that some threads were sometimes
> blocked
> on a synchronized block in grizlly framework (multiple threads in
> the thread
> pool try to notify the same user, so they use the same handler
> concurrently).
>
> I have seen that a ConcurrentCometHandler has been added in grizzly
> framework in order to queue message for the same handler instead of
> using
> multiple threads that will block each others.
>
> This seems a good idea but I still don't understand why this is not
> handled
> by the NIO framework. If read/write operation are non blocking so why
> threads are blocked on heavy load ?
>
> Does anyone can explain me how comet write operation works; if a
> call the
> write on the response outputstream associated to the comet handler,
> will it
> block until all data are send to the client ?
>
> Do we need to configure a buffer size on the HTTP connection to
> decrease the
> time spent to write a event ?
>
> Thanks.
>
> William.
> --
> View this message in context: http://old.nabble.com/Concurrency-between-comet-handlers-on-heavy-load---NIO-question-tp30717577p30717577.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>