2314 and 2315 are the only two issues fixed (other than including rdocs.tar.gz in binary distribution file) since RC3.
-Tom On Fri, Mar 28, 2008 at 8:45 AM, Mike Herrick (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > http://jira.codehaus.org/browse/JRUBY-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129036#action_129036 > ] > > > Mike Herrick commented on JRUBY-2314: > ------------------------------------- > > Glad I mentioned it! Ok, I'll grab the branch and test within the hour. Are > the other changes listed somewhere? Thanks. This is likely what we'll be > releasing with. Timing splendid ;) > > > > > Buffer management defect in RubyIO library: Class ChannelStream > > ---------------------------------------------------------------- > > > > Key: JRUBY-2314 > > URL: http://jira.codehaus.org/browse/JRUBY-2314 > > Project: JRuby > > Issue Type: Bug > > Components: Core Classes/Modules > > Affects Versions: JRuby 1.1RC3 > > Environment: All > > Reporter: Milton Taylor > > Assignee: Charles Oliver Nutter > > Priority: Critical > > Fix For: JRuby 1.1 > > > > > > I was having a problem where larger http POST operations was resulting in > truncation of data coming into the Ruby ActionController. I debugged this > under Eclipse and discovered the following: > > In class ChannelStream there is a method: > > private ByteList bufferedRead(int number) > > This method reads from an input channel and transfers the data into a > ByteList. Since the data can be returned by the channel reader in chunks, > there is a loop to read it chunk by chunk, appending it into the ByteList > called result. However, the loop control has an apparent fault in it, which > results in only the first chunk being read. > > The relevant line is: > > while (read == BUFSIZE && result.length() != number) { // not > complete. try to read more > > I haven't analysed this too deeply, other than to observe that in my case, > the first call to read from the channel does not return all the bytes > available, even though there is room in the buffer. (I don't think the java > API guarantees that it will). By fiddling in the debugger, I confirmed that > if it went around the loop a second time the remaining bytes were indeed > collected. > > So, I modified the loop control to remove the first test, since that > seemed superfluous to me on superficial examination... > > while (result.length() != number) > > This appears to have fixed my problem, but could you please confirm that > my fix is correct, and that there aren't any other similar bugs in this > module? > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://jira.codehaus.org/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > <hr/> > <p> > To unsubscribe from this list please visit: > </p> > <p> > <a > href="http://xircles.codehaus.org/manage_email";>http://xircles.codehaus.org/manage_email</a> > > -- Blog: http://www.bloglines.com/blog/ThomasEEnebo Email: [EMAIL PROTECTED] , [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
