Why would file reading stop at 1124 bytes with this code?

[Sudsy]

Mickey Segal wrote:

res.setContentType("text/plain");
PrintWriter out = res.getWriter();
out.print(reportString);
out.flush();

Is there some problem using such code for a String of longer than 1124
bytes? Sometimes a longer String is sent without truncation to 1124 bytes,
but usually it gets truncated to 1124 bytes.

I hate to mention the obvious, but I don't see an invocation of
setContentLength here. I know from experience that not specifying
the length can give receivers conniptions.

 

[Mickey Segal]

I hate to mention the obvious, but I don't see an invocation of
setContentLength here. I know from experience that not specifying
the length can give receivers conniptions.

I will fiddle with setContentLength and the receiving code; one or both may
be the problem. Thanks for the helpful suggestion - books on Java I/O tend
to gloss over such issues.

It is so much harder debugging servlets than applets or applications,
particularly when the servlets interact with other programs.

 

[Mickey Segal]

Ah! You're not using that nasty available() thing at the receiver are you?
Available() may welll return 0 if not all the reply has arrived yet. This
is more likely to happen with larger strings. 1120 could be the size of
the
payload after the HTTP header that hapens to fit in one packet.

The receiver was similarly messed up and fixing that too fixed the problem.
Thanks to all for the help.

 

[Mickey Segal]

I hate to mention the obvious, but I don't see an invocation of
setContentLength here. I know from experience that not specifying
the length can give receivers conniptions.

Fixing the stream reading code in the receiving applet fixed the problem.
But should one also use setContentLength in the servlet? The only place
I've seen setContentLength used has been for persistent connections, but are
others just being sloppy?

 

[Sudsy]

Fixing the stream reading code in the receiving applet fixed the problem.
But should one also use setContentLength in the servlet? The only place
I've seen setContentLength used has been for persistent connections, but are
others just being sloppy?

In a word, yes! Not setting the content length, or setting it incorrectly
(such as when sending text but not counting the line termination characters
properly), can lead to problems which are a real pain to debug.
MOST of the time you can get away with it but there are terminal conditions
which can arise and bite you big time. That's why I grew suspicious at the
1124 (1024 + 100) byte margin you mentioned earlier.
Fair enough?