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.