Hi,
Hmm, now i realize that loosing events (long poll) may happen. I was under
the impression that the ConcurrentHandler's embedded queue would keep the
posted events until the next poll starts. However looks like this won't work
because the handler gets removed from the context after the response is
committed. We do have a problem. Because streaming doesn't always
(buffering proxy is one case) work I need to be able fall back on long
polling but loosing event is not acceptable. For long polling there should
be a way to keep a handler with an internal queue into the context but
temporarily marked as 'resumed' (so the posted events can be enqued but no
i/o will take place). When the next poll starts, the handler should be moved
to 'i/o enabled' state and any queued events written (as a batch).
This is a big problem for me and, I don't know yet how, I must find a
hack/workaround ... unless you have a better suggestion.
The '200 threads' pool would be for pushing/writing the response. Is this
number configurable?
In the 2nd app, the client is flash and an event is a flash movie frame that
can be from 0.5k to 100k. It's a way of simulating a progressive download
(to avoid rtmp)
Jeanfrancois Arcand-2 wrote:
>
> Salut,
>
> felixx wrote:
>> Hi and thanks for your comments and for 1.9.9
>> I want you guys to have a big hit at JavaOne so I'll take your word that
>> the
>> news will be good.
>> Regarding the number of threads used to execute the handlers, I just feel
>> that this way we play it safer and a bunch of lazy clients/weird network
>> condition will not affect everybody. Also I would like the latency to be
>> almost the same for everybody.
>> I have 2 scenarios/apps:
>> 1. small payload, under 1k, will try first streaming (I guess this is
>> lighter for the server) for each client and fall back to long polling if
>> the
>> client/network doesn't behave;
>
> That looks promising...but note that as soon as you long poll you may
> start loosing message in between reconnection.
>
>
>> 2. only streaming, payload can be big, 50-100K
>> There are to many variables so i'll stop here. So short story do you
>> think
>> having a bigger treads pool would help? 100-200 are not so expensive in
>> terms of memory & switching and if it helps to play it safer, why not?
>
> Here you means the thread pool for accepting request or pushing request?
> Take a look at:
>
> http://cometdaily.com/2008/04/01/new-technology-new-problems-delayed-pushes-operations/
>
> I agree 200 is not expensive, but depending on what your application
> does it may not be optimal. Are you writing large chunk?
>
> A+
>
> --Jeanfrancois
>
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>> Salut,
>>>
>>> felixx wrote:
>>>> Salut et merci, I have to say you almost convinced me :-)
>>>> 1. Can you share some results please, just to get an idea, not details.
>>>> What
>>>> I'm trying to achieve is not so big. Let's say 5000 long poll connected
>>>> clients, 2000 sent messages/s (I.e. 1 msg sent to 2000 clients).
>>> I need to ask my co-speaker as we were planning to do a big hit during
>>> JavaOne :-). Probably yes :-)
>>>
>>>
>>>> Is it true that their solution is close to what is considered to be
>>>> added
>>>> in
>>>> servlet 3.0?
>>> No, Servlet 3.0 is a complete re-think of Comet. Nothing from
>>> Grizzly/Jetty/Tomcat has been re-used. The new Async features build on
>>> top of the preliminary work done on those containers. The main features
>>> is to be able to suspend/resume the response and to be able to dispatch
>>> a suspended response to another resources. This is a subset of what
>>> Grizzly Comet supports (but I'm pretty sure a lot of framework will
>>> build on top of the 3.0 api).
>>>
>>>
>>>> If detecting when the client is not present or able to receive messages
>>>> anymore it's based on catching an IOEx when writing the response, based
>>>> on
>>>> what I've seen using Tomcat, I'm not sure how well this will work. To
>>>> be
>>>> really sure I would rather have a client timeout mechanism on the
>>>> server
>>>> to
>>>> detect disconnected clients (check when the last ping event was
>>>> successfully
>>>> sent).
>>> Right, this is how you need to do that right now (except with Grizzly,
>>> who can detect a client close). With other, you need a thread that ping
>>> the connection to see if it is still open or not.
>>>
>>>
>>>> 2. I guess I was mislead by seeing in the examples the handler being
>>>> created
>>>> in doGet and by the doc saying: " ... Resume the Comet request and
>>>> remove
>>>> it
>>>> from the active CometHandler list. Once resumed, a CometHandler must
>>>> never
>>>> manipulate the HttpServletRequest or HttpServletResponse as those
>>>> object
>>>> will be recycled and may be re-used to serve another request. If you
>>>> cache
>>>> them for later reuse by another thread there is a possibility to
>>>> introduce
>>>> corrupted responses next time a request is made. ... "
>>>> So I should be able to cache it in client's session, attach the new
>>>> Response
>>>> in the nxt poll and then add it back to the context?
>>> Yes.
>>>
>>> I'll have to check the
>>>> code to understand how it works. I think it would be useful to be able
>>>> to
>>>> add the handler to the context using a custom ID. I'm wondering what
>>>> happens
>>>> if I add twice the same handler instance.
>>> The Handler will be invoked many times. But point taken...I will improve
>>> the javadoc on that front.
>>>
>>>> 3. I think this is explained in 2 now.
>>>>
>>>> 4. I need to understand how async http write would work. But anyway,
>>>> just
>>>> to
>>>> use a brutal approach, do you see a problem in having a pool of
>>>> 200-300
>>>> dispatching threads just to be sure?
>>> It really depend on what the application writes/payload. Can you
>>> elaborate?
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>>
>>>>
>>>> Jeanfrancois Arcand-2 wrote:
>>>>> Salut,
>>>>>
>>>>> felixx wrote:
>>>>>> 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
>>>>> 475: bad test (just recently added, OS dependent failure)
>>>>> 478: Javascript problem (and i'm quite bad with javascript)
>>>>> 479: Maybe an issue with cometd in GF v3.
>>>>>
>>>>> So nothing related to Comet (server side) :-). We lacked internal
>>>>> testing for awhile (situation fixed now :-)). Grizzly Comet is stable
>>>>> but true some minor release 1.9.x might introduce minor regressions).
>>>>>
>>>>> If your looking at an immature but nice Comet Framework, look at
>>>>> Atmosphere.dev.java.net (shameless plug as I'm releasing 0.1 today
>>>>> :-))
>>>>>
>>>>>
>>>>>> 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.
>>>>> That will be the topic of my javaone session this year :-) ...yes we
>>>>> have done some test with that but it really depends on the application
>>>>> itself, long poll vs http streaming, etc. We have two automated
>>>>> benchmark inside the workspace:
>>>>>
>>>>> https://grizzly.dev.java.net/nonav/xref-test/com/sun/grizzly/comet/CometUnitTest.html
>>>>>
>>>>> which can always be looked at. Of course they aren't real benchmark
>>>>> with
>>>>> a real application.
>>>>>
>>>>>
>>>>>> 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.
>>>>> Difficult to convince you here as Jetty was the first one on the
>>>>> market,
>>>>> and at the time GlassFish was just moving from its "zero" to its
>>>>> "hero"
>>>>> role :-). But the way Jetty handle suspend/resume cannot scale as
>>>>> every
>>>>> time you suspend, it throws an exception and your Servlet ends up
>>>>> being
>>>>> invoked twice. I like Jetty, but the way suspend/resume has been
>>>>> implemented cannot scale IMO and the logic needed inside a Servlet
>>>>> (double invokation) make the programming model complicated.
>>>>>
>>>>> Not only that, but with Jetty you don't have any support detecting
>>>>> when
>>>>> clients close connection (which can cause memory leak with some
>>>>> application because of wasted resources), something grizzly supports.
>>>>>
>>>>> Also the way information/message are pushed in Jetty has to be
>>>>> implemented by the application itself, where in Grizzly you can easily
>>>>> filter/throttle/push/cluster using the CometContext.notify() and
>>>>> NotificationHandler. This is less work to do for an application's
>>>>> developer.
>>>>>
>>>>>
>>>>>> 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?
>>>>> You don't have to recreate. Just re-add it to the list of suspended
>>>>> response (CometContext.addCometHandler())
>>>>>
>>>>> 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?
>>>>> CometHandler.attach() is for that. But you still need to invoke
>>>>> resumeCometHandler followed by addCometHandler()
>>>>>
>>>>>
>>>>>> 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.
>>>>> why do you think creating CometHandler are expensive? Event if they
>>>>> are
>>>>> (based on your application), you can alway use the
>>>>> CometHandler.attach()
>>>>> to recycle them. Did I misunderstood you?
>>>>>
>>>>>
>>>>>> 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?
>>>>> It's up to your application to either:
>>>>>
>>>>> + enable async http write in Grizzly (so no blocking thread) insid
>>>>> ethe
>>>>> application (grizzly internal will handle the "blocking" for you
>>>>> instead).
>>>>> + define a "strategy" inside NotificationHandler to detect such slow
>>>>> client and either discard them or park them inside a "queue" for later
>>>>> write.
>>>>>
>>>>> Note that the same issue will arise with Jetty :-)
>>>>>
>>>>>
>>>>>> 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.
>>>>> You are welcome. We have multiples implementation inside and outside
>>>>> Sun
>>>>> that build on top of Comet. One of them is our internal Sun IM
>>>>> product...so there is a possibility of ~30 000 users at the same time
>>>>> using it :-)
>>>>>
>>>>> Feel free to continue the discussion if I was unclear of if I missed
>>>>> the
>>>>> point.
>>>>>
>>>>> A+
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Thanks!
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/Grizzly-production-ready--ConcurrentHandler---scenarios-tp22501469p22579156.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.