Available returns an estimate of the number of bytes that can be read. It is free to say zero. Typically this would be a trigger for a sleep.
When we get a 0 followed by a 0, we read anyways. It is also worth noting the Javadocs give caution with regards to buffer allocation based on its value. > -----Original Message----- > From: Andreas Lehmkuehler <[email protected]> > Sent: Friday, February 26, 2021 2:28 AM > To: [email protected] > Subject: Re: test failures > > @Tilman Thanks for the pointer > > see https://issues.apache.org/jira/browse/PDFBOX-5111 > > Andreas > > Am 26.02.21 um 08:05 schrieb Tilman Hausherr: > > Am 26.02.2021 um 07:51 schrieb Andreas Lehmkuehler: > >> Hi, > >> > >> I've the same effects here and I already suspected the refactored io-code. > >> > >> @Tilamn: Good to hear that you already found the culprit. Do you already > >> have > >> a fix or should I have a look as well? > > > > > > I don't have a fix. Please have a look yourself too. I'm still kindof > > surprised > > that this would happen overnight despite no code change. Maybe some change > > on > > apache's own server. And the javadoc of available() reads like it's more > > about > > astrology. > > > > Tilman > > > > > >> > >> Andreas > >> > >> Am 26.02.21 um 07:30 schrieb Tilman Hausherr: > >>> It happens in RandomAccessReadBuffer(InputStream input) . > >>> > >>> input.available() returns 0 despite that more bytes are available. This > >>> can > >>> be shown with this change: > >>> > >>> > >>> if (remainingBytes == 0 && input.available() > 0) > >>> { > >>> expandBuffer(); > >>> } > >>> else > >>> { > >>> ////////////////////// new > >>> int by = input.read(); > >>> if (by != -1) > >>> { > >>> throw new IOException("hey there was more"); > >>> } > >>> ///////////////////// end of new code > >>> currentBuffer.limit(offset); > >>> break; > >>> } > >>> > >>> also, this test code > >>> > >>> @Test > >>> void testBlah() throws IOException > >>> { > >>> System.out.println("start"); > >>> try (InputStream is = new > >>> URL("https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf";).openStream()) > >>> > >>> { > >>> RandomAccessReadBuffer rarb = new RandomAccessReadBuffer(is); > >>> System.out.println(rarb.length()); > >>> } > >>> } > >>> > >>> shows 8192 bytes. The real size of the file is 34KB. > >>> > >>> > >>> Tilman > >>> > >>> Am 25.02.2021 um 20:26 schrieb Tilman Hausherr: > >>>> Something is weird with the trunk build. It fails on my PC and on Jenkins > >>>> despite no changes. > >>>> > >>>> An example is PDFontTest.testPDFox5048(). That one fails as it is, but > >>>> doesn't fail when using a local file. > >>>> > >>>> Also, the URL > >>>> > >>>> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf > >>>> > >>>> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not > >>>> when > >>>> loaded locally. > >>>> > >>>> Same test works fine when done in the 2.0 build > >>>> > >>>> Tilman > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
