Ow. That patch also can have issues.

101         public RandomAccessReadBuffer(InputStream input) throws IOException
102         {
103             this();
104             int bytesRead = 0;
105             int remainingBytes = chunkSize;
106             int offset = 0;
107             byte[] eofCheck = new byte[1];
108             while (true)
109             {
110                 while (remainingBytes > 0
111                         && (bytesRead = input.read(currentBuffer.array(), 
offset, remainingBytes)) > -1)
112                 {
113                     remainingBytes -= bytesRead;
114                     offset += bytesRead;
115                 }
116                 size += offset;
117                 if (remainingBytes == 0 && input.read(eofCheck) > 0)
118                 {
119                     expandBuffer();
120                     currentBuffer.put(eofCheck);
121                     offset = 1;
122                     remainingBytes = chunkSize - 1;
123                 }
124                 else
125                 {
126                     currentBuffer.limit(offset);
127                     break;
128                 }
129             }
130             seek(0);
131         }

input.read(eofCheck) == 0 is not an EOF!


Your loop should be something like:


int bytesRead;

try
{

while ( (bytesRead=read(buf,ofs,len)) != -1 )
{
  if (bytesRead == 0)
  {
    // do wait...
  }
  else
  {
   //analyze buffer management and make corrections
   //copy bytes
   //update buf, ofs, & len
  }
}

}
catch (...) / finally 
{
 //clean up
}

> -----Original Message-----
> From: Jason Pyeron <[email protected]>
> Sent: Friday, February 26, 2021 9:06 AM
> To: [email protected]
> Subject: RE: test failures
> 
> 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]
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to