[kaffe] DataInputStream related merge

Dalibor Topic robilad at yahoo.com
Tue Oct 8 03:57:45 PDT 2002

Hi Jukka,

--- Jukka Santala <jsantala at morphine.tml.hut.fi>
> Fairly straightforward merge from PocketLinux
> version, only problem is
> neither version of Kaffe has exact implementation.

could you give pat's serialization patch a try and see
how that works in your context?

You can find the details at:

> With Kaffe.org's
> version the problem is actually encountered, though
> - using Xerces XML
> parser, the HTTP code will eat out the headers using
> readLine, but then
> Xerces will use something else than DataInputStream
> to parse the remaining
> data. Because that reader doesn't know to eat the
> extra line-feed, it gets
> stuck at the beginning of the parse-input, which
> then doesn't fullfill the
> XML-production condition, and causes all XML
> documents read over HTTP to
> fail. If anybody can come up with an implementation
> that doesn't need
> mark()/reset(), I'd be happy. If not, this corrects
> few exception issues
> and at least works, unlike the old code :)

Hm. I'm not convinced. There are two ways to handle
the \r vs. \r\n ambiguity while reading lines. When a
line reading IO class reads a \r it can not tell if
that's the beginning of a \r\n newline sequence or
just a plain \r newline sequence. One can:
a) read one char ahead and check if it's \n; push it
back if it isn't.
b) set a flag to ignore the next char if it is \n.

I choose the second approach in all IO classes I
worked with in order to prevent the classical hung on
a socket bug. Imagine a client implementing method a
sending a request to a server, that returns a \r
terminated reply without closing the socket. The
client tries to read ahead and hangs because the
server has nothing left to send. Ugly.

Check out
for more information on this bug.

I switched DataInputStream to method b recently for
that reason. I don't think going back to the previous
version is a good idea, as it fixes one bug by
introducing another.

Instead of using mark and reset one could use a
pushback input stream with a single byte buffer, but
that's still method a.

In any case it would be great if you could come up
with a small test for the regression test suite as
this bug is not covered by it and we don't have that
many networking tests anyway.

It may be a bug in our HTTP handling code, for
example. A small test could help me come up with a
less invasive solution ;)

best regards
dalibor topic

Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More

More information about the kaffe mailing list