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 :).
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.
and so the pissing contest begins, just in a different area.
ok, the so the only thing required for the fix is
1. available() call on the intermediate stream
2. make sure the B2CConverter uses while(available) instead of while(true)
here is the 5.5 patch (had you actually taken a look at it)
http://people.apache.org/~fhanik/tomcat/b2c/patch.txt
nothing in there is 1.5-ish, hence I don't see your veto justified.
if you want to veto it, you have to come up with a reason why this patch
(see url) doesn't work
and possibly a different fix, since its a significant bug, and we are
tagging 5.5.25 on Friday
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]