Hello,
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.