users@grizzly.java.net

RE: Comet issue with requirement to close output streams

From: John C. Turnbull <ozemale_at_ozemail.com.au>
Date: Fri, 3 Jul 2009 04:41:43 +1000

Hi Jeanfrancois,

Thanks for the reply.

> That's probably because the Applet client is waiting for the last
> bytes,
> most probably \r\n\r\n...seems a bug on the client side IMO. When a
> connection gets suspended (Comet), the response is never committed and
> the last bytes not written...until you resume the connection. This is
> exactly what's happenning right now.
>
> Can you share a test case?

Yes, that would be no problem. But I posted the client code in my original
post and it's now doing nothing more than reading one byte at a time. I
really don't think it's a client-side issue. For the GZIP data, this is the
client code:

                                System.out.println("Reading...\n");
                                final GZIPInputStream gis = new
GZIPInputStream(this.stream);
                                int n = 0;
                                do {
                                        n = gis.read();
                                        System.out.print("[" + n + "] ");
                                } while (n != -1);

The output is "Reading..." and then nothing, not even one byte is read and
there should be no buffering happening here. (The variable "stream" is
returned from the call to the servlet).

If what you say is true, wouldn't you expect at least one byte to be read?

If I provide a test case, how would I do that i.e. where would I post it?
Send it to you directly?

Thanks,

John