[kaffe] DataInputStream related merge
robilad at yahoo.com
Tue Oct 8 03:57:45 PDT 2002
--- 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.
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
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 ;)
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
More information about the kaffe