"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Bill Barker wrote: >> "Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >>> 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 :). >>>> >>>> >>> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
