Salut,
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?
You are resuming the connection (under the hood you commit the response).
>
> If so, I think it would be helpful to mention that in the Javadoc.
Patches are welcome :-) :-)
>
>>>
>>> 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...
This is good them :-)
>
>> 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.
Let me know what you found.
A+
-- jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>