Fix smart HTTP client buffer alignment
commit882d03f70e089bfad2fe2e84f4f9cd69e805e332
authorShawn O. Pearce <spearce@spearce.org>
Fri, 12 Feb 2010 02:02:22 +0000 (11 18:02 -0800)
committerShawn O. Pearce <spearce@spearce.org>
Sat, 13 Mar 2010 00:08:14 +0000 (12 16:08 -0800)
treeef97df9c1d85fc64078a4494ea9a571e43d23459
parentd8c3e98d73a4fb7409580a7d9f3395ac506f7e5d
Fix smart HTTP client buffer alignment

This proved to be a pretty difficult to find bug.  If we read exactly
the number of response bytes from the UnionInputStream and didn't
try to read beyond that length, the last connection's InputStream is
still inside of the UnionInputStream, and UnionInputStream.isEmpty()
returns false.  But there is no data present, so the next read
request to our UnionInputStream returns EOF at a point where the
HTTP client code should have started a new request in order to get
more data.

Instead of wrapping the UnionInputStream, push an dummy stream onto
the end of it which when invoked always starts the next request and
then returns EOF.  The UnionInputStream will automatically pop that
dummy stream out, and then read the next request's stream.

This way we never get into the state where we don't think we need
to run another request in order to satisfy the current read request,
but we really do.

The bug was hidden for so long because BasePackConnection.init()
was always wrapping the InputStream into a BufferedInputStream
with an 8 KiB buffer.  This made the odds of us reading from the
UnionInputStream the exact number of available bytes quite low, as
the BufferedInputStream would always try to read a full buffer size.

Change-Id: I02b5ec3ef6853688687d91de000a5fbe2354915d
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
org.eclipse.jgit/src/org/eclipse/jgit/transport/TransportHttp.java