Salut,
Bill Robertson wrote:
> I have a situation where I am streaming comet responses. When I send each
> message, glassfish or grizzly appears to be chunking them.
>
> e.g.
>
> send a 33 byte message: 00028{"fu":"bar","messageId":"1"}
> flush the output stream
> send a 34 byte message: 00029{"fu":"bar2","messageId":"2"}
> flush the output stream
>
> The client receives this...
>
> 21\r\n
> 00028{"fu":"bar","messageId":"1"}\r\n
> 22\r\n
> 00029{"fu":"bar2","messageId":"2"}\r\n
>
> 21 (hex) == 33, so these are the message sizes.
>
> Chunking is new to me, so this is a bit of a surprise. I don't mind the
> behavior, but I would like to know if I can count on it happening?
Yes, by default Grizzly uses Chunking. This is specially important with
the Comet and http streaming as without chunking, that technique would
not have worked. Why? That's because with streaming we can't predict the
http body's lenght and appropriately set the content-lenght:XXX header
that tell the browser
In other
> words, can I take my length calculations out of the code and then tell 3d
> party clients to expect this the chunking behavior?
Yes
Will I get burned
> because the behavior in glassfish/grizzly might change?
Is it impossible that behavior will change. That will means Comet will
be forever broken, and all GF users broken...impossible :_)
Also, is there a
> maximum chunk size? i.e. could glassfish end up chunking in the middle of
> my message?
GlassFish has a extremely large buffer to use when chunking and never
stop chunking.
>
> BTW, this is the version of glassfish that was included in Netbeans 6.5 RC1.
Its v2 or v3 Prelude most probably. Are you using com.sun.grizzly for
the Comet API? If yes, you are using v3. If not, v2 or v3 :-)
A+
-- Jeanfrancois
>
> Thanks!
>