On Wed, 2008-02-27 at 12:51 -0700, Filip Hanik - Dev Lists wrote: > Bill Barker wrote: > > "Remy Maucherat" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > >> Filip Hanik - Dev Lists wrote: > >> > >>> Test Case and 5.5.x patch can be found here. > >>> http://people.apache.org/~fhanik/tomcat/b2c/ > >>> > >>> This is what is happening > >>> > >>> int cnt=conv.read( result, 0, BUFFER_SIZE ); > >>> is called with a "while (true)" statement, > >>> > >>> When the IntermediateInputStream.read returns -1, the above > statement > >>> returns cnt==1. > >>> So to avoid calling conv.read, we must check to see if we have > more bytes > >>> to read by implementing the available() method, to avoid the > inputstream > >>> ever returning -1. > >>> > >> It's possible, but I have a hard time understanding the issue. > >> > >> > > > > The issue is that InputStreamReader reads 8192 bytes from > > IntermediateInputStream on the first go. It then translates them > into 2734 > > chars, but thinks that the last few bytes represent an incomplete > char, so > > holds onto them. On the next call, IntermediateInputStream returns > -1, so > > InputStreamReader outputs the last char as best it can (resulting > in > > returning 1). Then the IntermediateInputStream buffer is reset, and > it can > > continue on reading (but from the wrong position, resulting in > corruption). > > > > Filip's patch is inelegant (better would be to use the ByteChunk > sink), but > > other than my looking for a better way to do it, I can't come up > with the > > required technical reason to porting the base of it to 5.5 (of > course, I > > could care less what he does in his sandbox :). > > > unfortunately, the "elegant" solution caused a regression :( > http://issues.apache.org/bugzilla/show_bug.cgi?id=44494 > I tested this with the inelegant (original proposed) patch and it > worked > fine, so I'm gonna fix this in trunk and propose the patch to 6.0
Ok, and there's no time to think ? A patch must be applied within the next 5 seconds ? (probably because it was not your patch, I assume :) ) Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
