Hi all,
I made good progress on this:
in your app:
add the bundler gem itself as a requirement to the Gemfile
preparation:
- export WEBAPP_HOME=
- unzip the .war
- unzip jruby-core-1.5.1.jar and jruby-stdlib-1.5.1.jar
- ln -s $WEBAPP_HOME/WEB-INF/lib/META-INF/jruby.home/bin /tmp/bin
this is necessary, because it couldn’t make it to set the RUBY
EXECUTABLE to another path. jgem env always shows “RUBY EXECUTABLE:
/tmp/bin/jruby”
5. ln -s $WEBAPP_HOME/WEB-INF/lib/META-INF/jruby.home/lib /tmp/lib
then you can call the console like this:
6. export GEM_HOME=$WEBAPP_HOME/WEB-INF/lib/META-INF/jruby.home/
7. export GEM_PATH=$WEBAPP_HOME/WEB-INF/gems/
8. cd $WEBAPP_HOME/WEB-INF/
9. java -cp lib/jruby-stdlib-1.5.1.jar -jar lib/jruby-core-1.5.1.jar
-I $WEBAPP_HOME/WEB-INF/lib/META-INF/jruby.home/lib/ruby/1.8 -I
$WEBAPP_HOME/WEB-INF/lib/META-INF/jruby.home/lib/ruby/gems/1.8/ -I
$WEBAPP_HOME/WEB-INF/gems/ -I
$WEBAPP_HOME/WEB-INF/lib/META-INF/jruby.home/lib/ruby/site_ruby/1.8
-S script/console production
and really, this will call the console!
But: it’s extremely slow in loading the source files.
Starting up the console on a modern machine takes about 5 minutes
a “kill -3” on the VM shows file system access stuff like this:
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at
java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:243)
at java.io.File.exists(File.java:750)
at
org.jruby.ext.posix.JavaSecuredFile.exists(JavaSecuredFile.java:119)
at org.jruby.RubyFileTest.file_p(RubyFileTest.java:137)
at
org.jruby.RubyFileTest$s_method_1_0$RUBYINVOKER$file_p.call(org/jruby/RubyFileTest$s_method_1_0$RUBYINVOKER$file_p.gen:65535)
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:146)
at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
or like that:
at java.io.UnixFileSystem.checkAccess(Native Method)
at java.io.File.canRead(File.java:708)
at
org.jruby.ext.posix.JavaSecuredFile.canRead(JavaSecuredFile.java:101)
at
org.jruby.runtime.load.LoadService.tryResourceFromLoadPath(LoadService.java:1086)
at
org.jruby.runtime.load.LoadService.tryResourceFromLoadPathOrURL(LoadService.java:993)
at
org.jruby.runtime.load.LoadService.findLibraryWithoutCWD(LoadService.java:766)
at
org.jruby.runtime.load.LoadService$NormalSearcher.trySearch(LoadService.java:491)
at
org.jruby.runtime.load.LoadService.findFileForLoad(LoadService.java:268)
at
org.jruby.runtime.load.LoadService.smartLoad(LoadService.java:313)
at org.jruby.runtime.load.LoadService.require(LoadService.java:357)
at
org.jruby.runtime.load.LoadService.lockAndRequire(LoadService.java:289)
- locked <0x00002aaab04902b8> (a java.lang.Object)
at org.jruby.RubyKernel.requireCommon(RubyKernel.java:984)
at org.jruby.RubyKernel.require(RubyKernel.java:967)
at
org.jruby.RubyKernel$s_method_1_0$RUBYFRAMEDINVOKER$require.call(org/jruby/RubyKernel$s_method_1_0$RUBYFRAMEDINVOKER$require.gen:65535)
at
org.jruby.internal.runtime.methods.JavaMethod$JavaMethodOneOrNBlock.call(JavaMethod.java:319)
I analyzed this closely and found out, that this happens only, if the
two jruby jar files are unzipped. It takes also 5 minutes to start up
the app in tomcat. Whenever it’s not unzipped, in tomcat it starts up
within about 15 seconds, but then of course I can’t start the console
again.
I used -Djruby.debug.loadService.timing=true and found out that the
normal jruby boot process is ok, but it looks like when the system
starts loading active_support, it slows down:
→ script/…/config/boot
…
← script/…/config/boot - 6545ms
→ commands/runner
→ optparse
← optparse - 0ms
→ /wepapp/releases/20100821-2204/WEB-INF/config/environment
→ /wepapp/releases/20100821-2204/WEB-INF/config/boot
← /wepapp/releases/20100821-2204/WEB-INF/config/boot - 3ms
→ ruby_version_check
← ruby_version_check - 8ms
→ jruby/util
← jruby/util - 0ms
→ rubygems
← rubygems - 0ms
→ active_record
→ active_support
→ active_support/vendor
…
← active_support/vendor - 956ms
and this continues many minutes. Here’s another excerpt from the output:
→ active_support/core_ext/range
→ active_support/core_ext/range/conversions
← active_support/core_ext/range/conversions - 951ms
→ active_support/core_ext/range/overlaps
← active_support/core_ext/range/overlaps - 959ms
→ active_support/core_ext/range/include_range
← active_support/core_ext/range/include_range - 922ms
→ active_support/core_ext/range/blockless_step
← active_support/core_ext/range/blockless_step - 905ms
← active_support/core_ext/range - 4658ms
Any ideas about these loading times probs?
thanks, Heiko S.
On 22.08.2010 01:00, Heiko S. wrote:
It would be a lot easier and consistent to maintain the production
http://xircles.codehaus.org/manage_email
–
Heiko S.
Dr. Alfred-Neff-Str. 15
75015 Bretten
Telefon: +49 7252/97 54 07
Mobil: +49 179/836 60 10
Email: [email protected]