Hi all,
I'm trying to decide on a Comet server side solution. My first preference
would be to go GF V3 and Grizzly. However based on the existing issues list
(475, 478, 479) I do have some concerns regarding the stability/maturity of
the Comet implementation. Here are some questions please:
1.Do you guys know/used the Grizzly Comet in a real production env. I know,
small examples with a few clients would work but how about having 5000
clients and 2000 messages/s? Has anyone tested/benchmarked such a scenario.
It would be unacceptable for us to have the app hanging or being unreliable
(see the above issues) I've seen some references about GF performance but
I'm referring strictly to the Comet side. Not easy to say it but, and I may
be wrong, it looks like Jetty has been used in such scenarios, worked fine
and seems more mature in this area.
2.Maybe I'm missing something here but is there a way to avoid recreating a
CometHandler every time the same client reconnects for a long pool? I would
need a ConcurrentHandler type (with the internal event queue) and seems
expensive to have for each poll cycle thousands of handlers being created
and then dropped when an event has ocurred. Why not just being able to
replace the embedded Response and keep the existing handler as long as the
client is present?
3.Here's a scenario I've seen using a different 'long polling' solution. Due
to a network condition the server is not able to push the events and these
are accumulating in the handler's queue. (not always the server is able to
see right away that the client is not able to receive the events). The
client has a mechanism to detect if ping events are received and if not will
try again to connect. Now you will end having 2 handler for the same client,
the old one with some events in the queue, also blocking a thread, and the
fresh one. How can we handle this type of situations in? In a different
system I used just to detect the situation, replace the Response and start
pushing the content of the queue.
4.Even with a ConcurrentHandler you may end having a lot of threads blocked
because of slow clients. It looks like if you expect 5000 clients it's safer
to use let's say 400 threads to execute the handler. Any comments on this?
A lot of questions, I know. Again GF & Grizzly looks very promising, great
work so far, I'm not just sure, and I need your help to convince myself, it
is ready for a real life application.
Thanks!
--
View this message in context: http://www.nabble.com/Grizzly-production-ready--ConcurrentHandler---scenarios-tp22501469p22501469.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.