Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: JRuby 1.0.3
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:Linux FC5, JDK 6, JRuby 1.0.3, Rails 2.0.2 , activerecord-jdbc-adapter (0.7) , activerecord-jdbcpostgresql-adapter (0.7), BSF 2.4.0
-
Number of attachments :
Description
I have a Java test harness that uses the BeanScriptingFramework to invoke JRuby scripts which use activerecord-jdbc to persist testcase actions to a Postgresql database. For small numbers of transactions it behaves fine, but as the number of transactions increases (~600), I run out of Java Heap and/or have severe GC CPU issues. If I swap out the BSF/JRuby/activerecord-jdbc code with standard JDBC calls I have a flat memory profile (tested up to 8000 transactions). This tells me there is a memory leak somewhere in the BSF/JRuby/activerecord-jdbc chain and not elsewhere in my application.
Essentially the call stack that is causing the memory leak starts with BSFManager.eval("ruby", "(java)", -1, -1, script_source_as_string); (I load the script source once in a static block, so I am not leaking memory there). If I comment out the call to eval, the memory leak goes away.
I looked into the BSF source and essentially BSFManager.eval() just wraps a call to BSFEngine.eval() which passes the call off to the appropriate ScriptEngine implementation, in my case the JRubyEngine.
My JRuby script looks like so:
--------------
include Java
require "#{$establish_connection}"
reply = Reply.new
reply.packet = $reply
cta = ClientTestAction.new
cta.testcase_execution_id = $testcase_execution_id
- ... other field setters ...
cta.reply = reply # will automatically save the reply, and the reply.client_test_action_id as part of the relationship
cta.save!
#return the created id
cta.id
The reply packet is the largest number of bytes involved, and if I comment out the parts related to it, the memory situation improves somewhat, but I still run OOM. If I comment out everything but the first two lines (the 'include Java and require lines), and return 0, the memory leak goes away. This also leads me to believe the memory issue is not in the BSF, but farther down in either the JRubyEngine or in the activerecord-jdbc code.
I'd hate to have to rewrite my application to use JDBC or Hibernate to make it perform, since the JRuby/AR solution was more elegant as it leverages the AR model for the Rails-portion of the application. Would appreciate someone taking a look at this. Thanks, -Michael
I upgraded to JRuby-1.1RC2, activerecord-jdbc-adapter (0.7.2), and activerecord-jdbcpostgresql-adapter (0.7.2). The memory profile for my test scenario is much improved. When before it ran out of Heap at ~600 transactions, it now survives around 8K-10K transactions so 1 order of magnitude improvement. In addition, initial free Heap head room doubled from 10MB to 20MB. But that degrades smoothly over the length of the test, so there may still be some leaks to uncover. However, it's definitely a major improvement. Keep up the great work, and looking forward to when I can run 100K transactions.