tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/
Date Fri, 24 Aug 2007 06:06:38 GMT

"Filip Hanik - Dev Lists" <> wrote in message
> Bill Barker wrote:
>> "Filip Hanik - Dev Lists" <> wrote in message 
>>> Bill Barker wrote:
>>>> "Remy Maucherat" <> wrote in message 
>>>>> Filip Hanik - Dev Lists wrote:
>>>>>> Test Case and 5.5.x patch can be found here.
>>>>>> This is what is happening
>>>>>> int result, 0, BUFFER_SIZE );
>>>>>> is called with a "while (true)" statement,
>>>>>> When the returns -1, the above statement

>>>>>> returns cnt==1.
>>>>>> So to avoid calling, 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 :).
>>> I've committed the fix to 5.5, if you find a more elegant way of solving 
>>> the actual problem, feel free to revert it and commit another fix. I 
>>> don't care about the how, as long as there is a fix that will be 
>>> included in the tag 5.5.25 on Friday
>> No problem.  I can see how to do this better, but I'll wait until the 
>> weekend to commit (since it's not totally trivial, I don't want a one-day 
>> window for regression testing :).  That way 5.5.25 can go out with your 
>> patch.  It doesn't include the NIO dependancy (which was my only 
>> concern), so it works well enough for me for now.
> according to the KISS principle, your fix would have to be less than 4 
> lines changed to be "more elegant" :)

Yes, it is more than 4 lines, but most of them are deletes :).  I've done it 
already on my local machine here, in case anybody wants RTC on the 5.5.x 
branch (and Filip's test case passes with flying colors :).  I'm pretty much 
sure that there are no regressions for 5.5.x+, but I still need to look at 
3.3.x,  and 4.1.x.

If anyone is interested, I can post the patch files.  Otherwise, I'll assume 
that CTR is still in place, and you can veto it when I commit over the w/e 
;).  Of course, if this message was meant as a pre-emptive veto, then I 
won't bother.

> Filip 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message