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 (nike.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: Tue, 21 Aug 2007 19:48:26 -0700
Lines: 67
Message-ID: <fag84n$5fu$1@sea.gmane.org>
References: <20070821221541.7FD151A981A@eris.apache.org>
 <46CB7531.1040004@hanik.com> <46CB7F51.1030201@apache.org>
Sender: news <news@sea.gmane.org>


"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 :).

> Some parts of the patch look weird, in particular, the:
>
> +import java.nio.CharBuffer;
>

This I will -1 porting to 5.5.  That branch of the connectors is shared by 
3.3.x and 4.1.x, and it is already hard enough to get them to build on 
pre-1.4 JVMs.

>  /** Efficient conversion of bytes  to character .
>   *
> @@ -211,6 +212,18 @@
>  return super.read( cbuf, off, len );
>      }
>
> +    public final int read() throws IOException {
> +        return super.read();
> +    }
> +
> +    public final int read(CharBuffer cb) throws IOException {
> +        return super.read(cb);
> +    }
> +
> +    public final int read(char[] cbuf) throws IOException {
> +        return super.read(cbuf);
> +    }
> +
>
> Overall, it's a good candidate for the new process, I think.
>
> R�my 


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