Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of jak-tomcat-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@tomcat.apache.org
From: "Bill Barker" <wbarker@wilshire.com>
Subject: Re: Bug in B2C converter WAS: svn commit: r568307 -
 /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
Date: Wed, 22 Aug 2007 19:41:28 -0700
Lines: 58
Message-ID: <fais3k$cs2$1@sea.gmane.org>
References: <20070821221541.7FD151A981A@eris.apache.org>
 <46CB7531.1040004@hanik.com> <46CB7F51.1030201@apache.org>
 <fag84n$5fu$1@sea.gmane.org> <46CC8730.6040504@hanik.com>
Sender: news <news@sea.gmane.org>


"Filip Hanik - Dev Lists" <devlists@hanik.com> wrote in message 
news:46CC8730.6040504@hanik.com...
> Bill Barker wrote:
>> "Remy Maucherat" <remm@apache.org> wrote in message 
>> news:46CB7F51.1030201@apache.org...
>>
>>> 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 :).
>>
> 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.


> Filip 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org