Moving to users (last email to dev).
Jim Driscoll wrote:
> So, given the code I've already written, would it be safe to say that
> we'd turned it into "HTTP Streaming" if we removed the
> resumeCometHandler call, and the two calls to hidden.location?
Yes. This is exactly http-stream as the response are sent in chunk.
Grizzly never send the last chunk util you resume the connection or its
times out.
>
> Note that that still means that once it times out, the get loop will
> terminate.
Yes.
But if I put the hidden.location call into the POST function
> on the client, would that still work? (It works, I tested it, but I'm
> wondering if leaving all those dangling Handlers out there will
> eventually mess things up.)
By Handlers, you means CometHandler?
A+
-- jeanfrancois
>
> Jim
>
> P.S. I guess I should start posting these questions to User_at_grizzly,
> shouldn't I?
>
> Jim Driscoll wrote:
>> Blog about it here:
>> http://weblogs.java.net/blog/driscoll/archive/2008/05/dead_simple_com_1.html
>>
>>
>> If there's any inaccuracies, let me know and I'll fix them immediately.
>>
>> I basically just took the email I sent earlier and formatted it (and
>> then fixed the part I got wrong :-)
>>
>> Jim
>>
>> Jim Driscoll wrote:
>>> Jeanfrancois Arcand wrote:
>>>> Jim Driscoll wrote:
>>>> Looking at the code, I see:
>>>>
>>>>> if (CometEvent.NOTIFY == event.getType()) {
>>>>> int count = counter.get();
>>>>> PrintWriter writer = response.getWriter();
>>>>> writer.write("<script
>>>>> type='text/javascript'>parent.updateCount('" + count +
>>>>> "')</script>\n");
>>>>> writer.flush();
>>>>> //event.getCometContext().resumeCometHandler(this);
>>>>> }
>>>>
>>>> The resumeCometHandler is commented out. Which means the connection
>>>> is never closed when an event happens. Which means you are now using
>>>> http-streaming instead of long polling. So from that the connection
>>>> doesn't seems to be terminated, but instead stay in "comet state"
>>>> for 20 seconds.
>>>
>>> Drat. I had the actual meaning of the resumeCometHandler call
>>> exactly backwards.
>>>
>>> So by calling resumeCometHandler(this), I'm then closing the
>>> connection, in addition to removing the handler from the active queue?
>>>
>>> If so, I think it would be helpful to mention that in the Javadoc.
>>>
>>>>>
>>>>> Back at the client, that javascript that got sent down gets put
>>>>> into the hidden iFrame, and then executed. This calls the
>>>>> updateCount function, which updates the counter with the new
>>>>> value. Then, we set the iframes' location object, which reconnects
>>>>> with GET to the servlet, and we're ready for our next request.
>>>>>
>>>>
>>>> So, what happens if two iframes connect? Both connection will be
>>>> suspended and the browser might not be able to send any more data.
>>>> Let me compile your demo :-)
>>>
>>> No, it works, but apparently by accident - because there's only one
>>> iframe doing one connection at a time - the old connection is dropped
>>> whenever I do a hidden.location = url statement. So no deadlock is
>>> possible, so long as you only are doing a single Comet call...
>>>
>>>> So, to get around this, we
>>>>> add a single line at the end of our postMe function, updating the
>>>>> hidden iframe's location again. This is the one really hacky part
>>>>> of the program, and I'd love to know a better way to do it.
>>>>
>>>> My skills cannot help here....
>>>
>>> I've figured out how to do it, I think maybe, but I think it's a
>>> limitation of the hidden iframe method. I'd have to add second
>>> XMLHttpRequest object to do a GET, and sense the status of the
>>> connection... Something to try for later.
>>>
>>>
>>>> Also, it gives
>>>>> rise to the second bug of our program, related to the first - if
>>>>> the connection dies, you need to click the button twice to see an
>>>>> update of the counter on the client.
>>>>
>>>>
>>>> Right, as you first need to reconnect. I know this is possible to
>>>> do, but I don't know how to do that :-) I think you need to register
>>>> a callback that gets invoked when the connection die.
>>>
>>> I don't know of a way to do that with the location object - so I'd
>>> instead have to use a XMLHttpRequest object instead.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>