[jruby-dev] [jira] Created: (JRUBY-3631) RubyStringIO error when handling multipart/form-data in a Ruby on Rails app
RubyStringIO error when handling multipart/form-data in a Ruby on Rails app --- Key: JRUBY-3631 URL: http://jira.codehaus.org/browse/JRUBY-3631 Project: JRuby Issue Type: Bug Components: Core Classes/Modules Affects Versions: JRuby 1.2 Environment: OS X 10.5.6 JRuby 1.2.0 Rails 2.3.2 Java 1.6.0_07 mongrel 1.1.5 / jetty_rails 0.8 / glassfish gem 0.9.3 Safari 4 / Firefox 3.0.10 Reporter: George Agnelli Priority: Blocker Attachments: rails-upload-test.zip When posting a form with multipart/form-data encoding I get the following exception and the rails controller action is never executed. This happens for me every time whether or not there is any data in the form fields. I have tested with mongrel 1.1.5, jetty_rails 0.8, glassfish gem 0.9.3 and the result is the same. I have attached the view and controller from a rails application that is experiencing this issue. Exception in thread Thread-12 java.lang.ArrayIndexOutOfBoundsException at org.jruby.util.ByteList.grow(ByteList.java:616) at org.jruby.util.ByteList.unsafeReplace(ByteList.java:335) at org.jruby.util.ByteList.replace(ByteList.java:351) at org.jruby.RubyStringIO.read(RubyStringIO.java:605) at org.jruby.RubyStringIO$i_method_0_2$RUBYINVOKER$read.call(org/jruby/RubyStringIO$i_method_0_2$RUBYINVOKER$read.gen) at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:624) at org.jruby.RubyClass.finvoke(RubyClass.java:391) at org.jruby.RubyObject.send(RubyObject.java:1409) at org.jruby.RubyObject$i_method_multi$RUBYINVOKER$send.call(org/jruby/RubyObject$i_method_multi$RUBYINVOKER$send.gen) at org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:199) at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:206) at org.jruby.ast.CallSpecialArgBlockPassNode.interpret(CallSpecialArgBlockPassNode.java:68) at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104) at org.jruby.ast.BlockNode.interpret(BlockNode.java:71) at org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:259) at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:189) at org.jruby.RubyClass.finvoke(RubyClass.java:410) at org.jruby.javasupport.util.RuntimeHelpers.invoke(RuntimeHelpers.java:382) at org.jruby.javasupport.util.RuntimeHelpers.callMethodMissingInternal(RuntimeHelpers.java:356) at org.jruby.javasupport.util.RuntimeHelpers.callMethodMissing(RuntimeHelpers.java:324) at org.jruby.runtime.callsite.CachingCallSite.callMethodMissing(CachingCallSite.java:351) at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:290) at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:152) at org.jruby.ast.CallTwoArgNode.interpret(CallTwoArgNode.java:59) at org.jruby.ast.DAsgnNode.interpret(DAsgnNode.java:110) at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104) at org.jruby.ast.BlockNode.interpret(BlockNode.java:71) at org.jruby.ast.UntilNode.interpret(UntilNode.java:120) at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104) at org.jruby.ast.BlockNode.interpret(BlockNode.java:71) at org.jruby.runtime.InterpretedBlock.evalBlockBody(InterpretedBlock.java:192) at org.jruby.runtime.InterpretedBlock.yield(InterpretedBlock.java:143) at org.jruby.runtime.Block.yield(Block.java:100) at org.jruby.RubyKernel.loop(RubyKernel.java:1084) at org.jruby.RubyKernel$s_method_0_0$RUBYFRAMEDINVOKER$loop.call(org/jruby/RubyKernel$s_method_0_0$RUBYFRAMEDINVOKER$loop.gen) at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:263) at org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:81) at org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:96) at org.jruby.ast.FCallNoArgBlockNode.interpret(FCallNoArgBlockNode.java:32) at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104) at org.jruby.ast.BlockNode.interpret(BlockNode.java:71) at org.jruby.ast.IfNode.interpret(IfNode.java:112) at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104) at org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:163) at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:144) at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:273) at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:112) at
[jruby-dev] [jira] Created: (JRUBY-3632) Jruby deployment missing batch files
Jruby deployment missing batch files Key: JRUBY-3632 URL: http://jira.codehaus.org/browse/JRUBY-3632 Project: JRuby Issue Type: Bug Affects Versions: JRuby 1.3RC1 Environment: Windows Reporter: Michael Sofaer Assignee: Thomas E Enebo Priority: Minor Fix For: JRuby 1.3RC1 rake.bat and spec.bat are not present in the bin folder -- 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 - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [jruby-dev] [jira] Created: (JRUBY-3628) java.util.logging misbehavior when called from JRuby
Morten,
At great risk of opening a java logging APIs debate, you might consider
using the slf4j and logback gems (http://rjack.rubyforge.org/) for your
logging needs.
In particular, the combination supports aggregating logging from all
common APIs/sources including java.util.logging, and logging from ruby
is via a ruby-core Logger compatible adapter to SLF4J, and slf4j/logback
doesn't insist on using callers java class name in the output:
require 'rubygems'
require 'logback'
Logback.config_console( :full = true )
log = SLF4J['com.test.xxx']
log.info 'logging from jruby'
2009-05-08 14:40:05,382 INFO com.test.xxx - logging from jruby
BTW: slf4j - java.util.logging shows the same NativeMethodAccessorImpl
class name. Not sure if you can replace that field in the output with a
given name instead (like with logback,log4j, etc.) I doubt this is a
jruby problem per say.
--David
On Thu, 2009-05-07 at 06:47 -0500, Morten Christensen (JIRA) wrote:
java.util.logging misbehavior when called from JRuby
Key: JRUBY-3628
URL: http://jira.codehaus.org/browse/JRUBY-3628
Project: JRuby
Issue Type: Bug
Components: Core Classes/Modules, Java Integration
Affects Versions: JRuby 1.2
Environment: Java 1.6, JRuby 1.2
Reporter: Morten Christensen
l
When calling Java's java.util.logging system within Jruby, the logger name is
wrongly set to sun.reflect.NativeMethodAccessorImpl instead of the logger
name specified by the call to Logger. Apart from making things difficult when
reading the log, this also cause the normal java log filters to malfunction
(i.e the log messages from jruby may not appear unless a special/default log
level is set to log sun.reflect also). This is a major problem with
java/jruby projects, as proper logging behavior is essential for production
systems!
To reproduce try this under IRB:
log = java.util.logging.Logger.getLogger('com.test.xxx')
log.addHandler(java.util.logging.ConsoleHandler.new())
log.log(java.util.logging.Level::SEVERE, 'Logging from JRuby')
The correct result would be something like:
May 7, 2009 1:31:13 PM com.test.xx ???
SEVERE: Logging from JRuby
But JRuby 1.2 incorrectly writes:
May 7, 2009 1:31:13 PM sun.reflect.NativeMethodAccessorImpl invoke0
SEVERE: Logging from JRuby
Re: [jruby-dev] JRuby IR: First thoughts
Subramanya Sastry wrote: I may have been wrong. I had a chance to think through this a little bit more. Consider this ruby code: i = 5 v1 = i + 1 some_random_method_call() v2 = i + 1 In this code snippet, the second '+' might not get optimized because 'some_random_method_call' could monkeypatch Fixnum.+ in the course of whatever it does. This means that calls form hard walls beyond which you cannot hoist method and class modification guards (unless of course, you can precisely determine the set of methods any given call can modify -- for example, that 'some_random_method_call' will not modify Fixnum.+). This is certainly a challenge for entirely eliminating guards, and I believe even the fastest Ruby implementations currently are unable to remove those guards completely. In this example, if we can at least prove that i, v1, and v2 will always be Fixnum when Fixnum#+ has not been replaced, we can emit guarded optimized versions alongside deoptimized versions. Because Fixnum#+ falls on the rarely or never replaced end of the spectrum, reducing + operations to a simple type guard plus Fixnum has been modified guard is probably the best we can do without code replacement. More on code replacement thoughts later. So, this is somewhat similar to pointer alias analysis in C programs. In C programs, the ability to pass around pointers and manipulate them in an unrestricted fashion effectively restricts the kind of optimizations that a compiler can do. Similarly, in Ruby programs, it seems to me that the ability for code to arbitrarily modify code effectively restricts the kind of optimizations that a compiler can do. Open classes and eval and all of that are to Ruby what pointers are to C. Potentially powerful for the programmer, but hell for the compiler. More on this further below after discussion of the multi-threaded scenario. It is true that we generally must assume code modification events will have a large impact on core methods. This means we need to always guard, even if such modifications are exceedingly rare. However it may be pessimistic to assume such guards will be unacceptably slow in comparison to the rest of the system, when this may or may not be the case. Currently, all method calls in normal execution scenarios must read a volatile field for the call site invalidation guard. Although it's difficult to measure accurately, the volatile guard should in theory be a very large expense, and John Rose said as much when I described our current system to him. But it may be possible to make such guards non-volatile if we have other mechanisms for triggering memory synchronization that those non-volatile calls could see. One theory I had was that since we periodically ping another volatile field for cross-thread events (kill, raise), there may be a way we can rely on those events to trigger our memory sync. But I am unfamiliar enough with the Java memory model that I do not know if such a volatility-reducing mechanism would work or be reliable. If thread 2 modifies Fixnum.+, you might expect the modification to be reflected in thread 1 at some point. If you hoist method/class guards all the way outside the loop and convert the i+1 to integer addition, code modifications from thread 2 won't propagate to thread 1. But, in this scenario, I would argue that any code that relies on behavior like this is broken. This is effectively a race condition and different ruby implementations will yield different behavior. In fact, code modification by meta-programming is effectively modifying class meta-data. So, concurrent code modification is not very different from concurrent writes to program data. I am not sure if the meta programming model treats modification to open classes as changes to a program-visible meta-data. If it were, then programmer can then synchronize on that meta-data object before patching code. But, I expect this is not the case because that would then force every method call to acquire a lock on the class meta-data. Again there's some unknowns here, but the likelihood of method table modifications happening across threads (or at least the likelihood of those changes producing runtime behavioral effects across threads) is probably very low. The majority of Ruby libraries and frameworks have either been designed with single threads in mind--i.e. the expectation is that a given thread would exit the library before a code modification would happen, if it ever did--or have been designed with multi-threading in mind--making code modifications at boot time or with an expectation that only one thread would ever see them (like modifying a thread-local object to add new methods or modules). Both cases have few expectations about vigorous or even common cross-thread code modification events. Where does this leave us? Consider a Rails app where there is a UpdateCodeController with a method called
