I'm guessing that this would be something related to the way that RJB works. JRuby is almost always more reliable when it comes to invoking Java stuff, so that's the way I would go for a build server. Actually, I'm surprised I didn't think of that earlier! The only disadvantage to using JRuby is poor startup performance. This isn't a problem on a build server, and seeing that JRuby's long-run performance far outstrips MRI, you may actually reap some build time improvements from the switch.
Daniel On Fri, Aug 21, 2009 at 4:36 AM, Martin Grotzke < [email protected]> wrote: > Hi, > > our builds now are failing more often with "could not connect to > compilation daemon" on our build server, it's getting a bigger issue for > us as developers don't notice failed builds. > > So we tried several things and found out that the scala compiler doesn't > crash when buildr is run using jruby. Any idea what's the reason for > this? > > Cheers, > Martin > > > PS: I also tried increasing the thread stack size using -Xss and/or > -XX:ThreadStackSize, but this didn't help. > > > On Fri, 2009-08-07 at 14:07 -0500, Daniel Spiewak wrote: > > > > > > Why wouldn't you recommend to use fsc? > > > > > > FSC is designed to be solely used as a time saver during local > development > > (saving on VM startup and classloading time). To do this, it keeps a lot > of > > stuff floating in a cache. The danger with this approach is it sometimes > > leads to very strange stale cache values, particularly when dependent > > libraries change. This is manageable on a local machine when a real > person > > can catch the problem and immediately rectify the situation, but a CI > server > > is supposed to run as independently as possible. The CI build should > live > > and die on the merits of the code, not some flaky cache held in a > persistent > > process.Nope, no stack trace. > > > > Yes, I just tested this, then the output is like this: > > > > > > Compiling ff:processing into > > > /home/grotzke/proj/freiheit/final_folder/processing/target/classes > > > Buildr aborted! > > > Scala compiler crashed: > > > #<StackOverflowError: unknown exception> > > > > > > Cool! ?! :) (it's good to have this improved error reporting ;)) > > > > > > > Well, I'm not perfect! :-) StackOverflowError does tell us something. > > There are now two possibilities. One would be that the scala compiler > has a > > bug that your code is unearthing (it wouldn't be the first time). The > other > > possibility is that the compiler's stack is legitimately getting to be > too > > deep for the VM to handle. This happens on occasion actually. The > solution > > is to use the -X JVM options to allocate some of the stack onto the heap. > > You'll have to lookup the exact options, but I know they exist (I've used > > them a few times). I would try that, see if the build runs after that > > little tweak. > > > > Otherwise, the only workaround (other than waiting for the Scala team to > fix > > whatever is causing this) would be to use FSC and deal with any weirdness > > which results. > > > > Daniel >
