RoR refreash/caching strangeness

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.0.0RC2
  • Fix Version/s: JRuby 1.0.0RC3
  • Component/s: Application Error
  • Labels:
    None
  • Environment:
    Windows XP+Rails 1.2.3 + Java6 + JRuby RC2

Description

I get some strange behavior on all my web pages. The weird behavior did not happen in RC1 and does not happen under normal Ruby:

First time I go to a webpage, nothing happens but if I refresh the page, it typically shows up ok... However, at least for the index page I get the followin text written out at the top of my page above my content:

"Content-Type: text/html; charset=utf-8 Set-Cookie: ...=...; path=/ Content-Length: 5423 Cache-Control: no-cache Status: 200 OK"

Very, very strange!

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

This is a potential regression from RC1...we need to investigate, but there's not a lot to go on. Morten, we need more info or a sample app or a reducible test case to really be able to work on this one...

Show
Charles Oliver Nutter added a comment - This is a potential regression from RC1...we need to investigate, but there's not a lot to go on. Morten, we need more info or a sample app or a reducible test case to really be able to work on this one...
Hide
Permalink
Morten Christensen added a comment -

If you have not heard about this before, I suspect this is not something to do with my application but with my environment (Windows XP+Rails 1.2.3 + Java6 + JRuby RC2).

Anyway, I will create a new sample application shortly and see if I can reproduce the behavior.

Show
Morten Christensen added a comment - If you have not heard about this before, I suspect this is not something to do with my application but with my environment (Windows XP+Rails 1.2.3 + Java6 + JRuby RC2). Anyway, I will create a new sample application shortly and see if I can reproduce the behavior.
Hide
Permalink
Charles Oliver Nutter added a comment -

We just had another report about this, oddly enough. So I think it is a regression. I'm bumping it up to a blocker.

Show
Charles Oliver Nutter added a comment - We just had another report about this, oddly enough. So I think it is a regression. I'm bumping it up to a blocker.
Hide
Permalink
Morten Christensen added a comment -

Yea, it is a very strange yet pretty critical thing.... Charles, did you get my email about this that I send to you Sun email account on May 22 ?

Show
Morten Christensen added a comment - Yea, it is a very strange yet pretty critical thing.... Charles, did you get my email about this that I send to you Sun email account on May 22 ?
Hide
Permalink
Charles Oliver Nutter added a comment -

If this is unicode related, it may be looking better now. Can you retest?

Show
Charles Oliver Nutter added a comment - If this is unicode related, it may be looking better now. Can you retest?
Hide
Permalink
Charles Oliver Nutter added a comment -

Ok, I have a fix for this. The problem is that the logic for writing a string to an IO channel was not using the "begin" index in ByteList for that write. So if we have a larger buffer, like a full page contents, and we create a new string that shares the backing store but with an index != 0 (or modify the existing string by chopping off the beginning, writes of that new string would still write from the beginning of the buffer.

This also explains why the end of the buffer got cut off: It wrote from the beginning of the buffer, but with the string's actual length. So an equal number of characters got chopped off the end.

I don't know how to write a test for this at the moment, since the code is in IOHandlerNIO. We'd need something that writes to a socket and confirms that a copy-on-write string is writing correctly...

Show
Charles Oliver Nutter added a comment - Ok, I have a fix for this. The problem is that the logic for writing a string to an IO channel was not using the "begin" index in ByteList for that write. So if we have a larger buffer, like a full page contents, and we create a new string that shares the backing store but with an index != 0 (or modify the existing string by chopping off the beginning, writes of that new string would still write from the beginning of the buffer. This also explains why the end of the buffer got cut off: It wrote from the beginning of the buffer, but with the string's actual length. So an equal number of characters got chopped off the end. I don't know how to write a test for this at the moment, since the code is in IOHandlerNIO. We'd need something that writes to a socket and confirms that a copy-on-write string is writing correctly...
Hide
Permalink
Charles Oliver Nutter added a comment -

Huzzah! Another blocker fixed! Committed in 3777.

Show
Charles Oliver Nutter added a comment - Huzzah! Another blocker fixed! Committed in 3777.
Hide
Permalink
Morten Christensen added a comment -

See "http://jira.codehaus.org/browse/JRUBY-1091" for the remaining issues with this problem in RC3

Show
Morten Christensen added a comment - See "http://jira.codehaus.org/browse/JRUBY-1091" for the remaining issues with this problem in RC3
Hide
Permalink
Morten Christensen added a comment -

Sorry, I meant "http://jira.codehaus.org/browse/JRUBY-1092"

Show
Morten Christensen added a comment - Sorry, I meant "http://jira.codehaus.org/browse/JRUBY-1092"

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Morten Christensen
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: