Bug 42834 - RawDataBlock makes incorrect assumption about size of data returned by IOUtils.readFully()
Summary: RawDataBlock makes incorrect assumption about size of data returned by IOUtil...
Alias: None
Product: POI
Classification: Unclassified
Component: POIFS (show other bugs)
Version: 3.0-FINAL
Hardware: Other other
: P2 normal with 3 votes (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on:
Reported: 2007-07-08 07:57 UTC by Paul King
Modified: 2008-01-09 08:35 UTC (History)
0 users

patch (1.32 KB, patch)
2007-07-08 07:58 UTC, Paul King
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paul King 2007-07-08 07:57:34 UTC
RawDataBlock assumes that IOUtils.readFully() returns data in blocks that are
POIFSConstants.BIG_BLOCK_SIZE in size. When reading an Excel file out of a Jar
or from a socket or http client connection with no buffering, this appears not
to be the case. It appears to be an issue with all reads on a slow server (e.g.
crystal reports generating the PDF on a heavily loaded machine or across a slow
network) and an issue for the last read when crystal reports is running locally
on a lightly loaded machine. The fix seems to be to remove the code which checks
if the  size returned is a multiple of POIFSConstants.BIG_BLOCK_SIZE as per the
attached patch. At least that has worked for the latest few versions of crystal
Comment 1 Paul King 2007-07-08 07:58:31 UTC
Created attachment 20478 [details]
Comment 2 Paul King 2007-07-29 20:21:30 UTC
Possibly the same as 28231 which has a similar issue but a slightly different fix.

Related to 13478 which provided a partial but incomplete fix (as far as I can tell).
Comment 3 Nick Burch 2007-12-04 04:37:13 UTC
I'm tempted to say that we ought to throw an error if the last data block is
short, but handle the case of a slow read meaning we don't get all of a data
block in one go. That'll need a little bit more code than the patch offers though
Comment 4 Nick Burch 2008-01-09 08:35:35 UTC
I've written a test which works with a very slow inputstream. With this, I don't
have any problems reading a whole block, even if done so in lots of tiny little
bits with gaps. I've also tweaked the comments/javadocs/exception text to ensure
they're clear on exactly what will and won't work

You should only get the IOException if your stream EOFs in the middle of reading
a block, which should never be the case for a valid OLE2 document (which is
required to be a multiple of the blocksize)

So, I'm not sure what your problem is, but I think it isn't related to

If you're still getting this issue after trying with a svn checkout from trunk,
could you put together a unit test that demonstrates the issue? (My slow reading
unit test couldn't trigger it, so we will need a failing unit test to be able to
replicate the issue, if it's still present)