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?
Note that that still means that once it times out, the get loop will
terminate. 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.)
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
>