Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Not A Bug
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Rails WAR Deployment
-
Labels:None
-
Environment:JRuby 1.1.6 / Rails 2.0.2 / Glassfish v2ur2 / Java 6.0 (HotSpot)
-
Number of attachments :
Description
Not sure where to post this, but thought I would try here, as I think this could be stemming from a larger runtime issue... would love to hear any feedback from the team...
We have a largish (60+ models, 300+ migrations) Rails 2.0.2 application that we've deployed on Glassfish v2 on JRuby 1.1.6. So far we haven't really hit any issues w/our move from MRI to JRuby – kudos! – except (seemingly) a chronic issue with some actions blowing the stack & popping SystemStackError 'stack level too deep' exceptions. In some instances, these actions just seem to hang the GF request, raising no runtime exception at all. We've tried changing our -Xss setting for our GF process to as high as 10m & can still reproduce this behavior. It seems almost all of these are POST/write-heavy actions rather than GET/read-only.
I should also mention that we are deploying a fairly non-trivial rails app – most requests can trigger several observer/AR callbacks often across a couple class hierarchies & we also do a fair bit of dynamic runtime extension (Module#extend on each controller instance) to mix-in behavior according to what kind of request we are serving. These things together could possibly blow the stack (esp if chained together by callbacks), but as I mentioned above, changes to stack size always seem to yield the same result. Also, we've never seen this on MRI – and we've been running this application in production for over a year now.
We are thinking of upgrading to 2.2 and seeing if we can repro but thought I would check here first to see if this could possibly be a symptom of a larger issue w/the runtime.
Here is a link to a some sample stack traces: http://pastie.org/345302
Our JVM options for our GF server are (as specified in the admin console):
-server -XX:+UseParallelOldGC -XX:ParallelGCThreads=4 -XX:+DisableExplicitGC -XX:NewRatio=2 -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m -Xss10m
And we are running a static pool of 2 runtimes.
Charles, went ahead & tried running under trunk with $DEBUG = true. At first I was getting LoadErrors when visiting pages, but it turned out that moving the $DEBUG declaration after the rails initializer block fixed it.
We are now getting stranger errors:
http://pastie.org/345908
It looks like the "too many arguments for format string" is a known issue with debug mode in 2.x rails:
http://dev.rubyonrails.org/ticket/8970
Any subsequent requests to actions that raise that ArgumentError will have LoadErrors (as illustrated in that paste).
Is there another way to trigger the full java stack dump without using $DEBUG?