Spork compatible about akephalos HOT 18 OPEN

I also see this problem on Ruby 1.9.2 p0.

from akephalos.

And ruby 1.9.2p180, and Spork 0.9

from akephalos.

It seems to be a problem with garbage collection. I tried setting the minimum memory for the VM to be 512 MB in order to minimise Garbage collection (the default is 64 mb). But the results are the same, all test fails with the recycled object error.

Upgrading to the last jruby-jar didn't solve the problem either (but hey, all akephalos' tests pass).

I tried disabling GC, but being JRuby the statement GC.disable doesn't do anything.

Mmm....

from akephalos.

doesn't help much, but I can confirm the problem for ruby 192p180, spork 084
--Frank

from akephalos.

I can also confirm the problem with akephalos 0.2.5 and spork 0.9.0.rc4

from akephalos.

I too can see this issue, Ruby 1.9.2, Spork 0.9.0.rc4, Akephalos 0.2.5

from akephalos.

Let wait for @bernerdschaefer insight :)

from akephalos.

Also have this issue on Ruby 1.9.2 spork 0.9.0.rc Akephalos 0.2.5

from akephalos.

Any ideas on this? I would be happy to delve in if someone has a place to start. Seems like a GC issue but I defer to the experts.

from akephalos.

It is a problem with the GC. Akephalos uses HTMLUnit, which runs on JRuby. I suspect that some object is being garbage collected in the JRuby part. But I haven't figure it out where and I am no an expert at JRuby either :)

I have tried increasing the available memory that the java virtual machine can use, but the problem persists.

from akephalos.

I will take a look into this over the next week during my free time.

from akephalos.

I'm totally new to akephalos and never used spork but this type of error can occur with DRb if the DRb server creates an object, doesn't keep a reference to it, and a client doesn't immediately request it. The server will GC the object and the client will get another object after the GC. The server side might need to keep a class variable hash (which won't be GC'd) with references to an object at creation and remove it when the client requests it. Either that, or don't instantiate transient objects until they're requested. You would have to see where the DRb objects are instantiated, in akephalos or in spork, and actually used.

from akephalos.

Great hint. I will boot up a new rails 3 app tonight to see if I can figure out what specifically is being GC'd then requested.

from akephalos.

@lightsofapollo: How did it go? Any improvements?

from akephalos.

Nothing yet, still working on it. Taking some time off in three weeks. I will be able to focus more on it then if I don't figure it out in my spare time before then. Like your fork by the way.

from akephalos.

I don't think this is a GC issue - the issue appears to be that when test codes talks to akephalos' remote drb object it uses the wrong uri when constructing proxy object for blocks, so ruby then tries to invoke the block in the spork parent process rather than the process actually running the features/specs (note that in the backtrace the error is thrown from druby://127.0.0.1:8989 which is the uri for the service spork advertises).

I've put a longer discussion along with a workaround that works for my cucumber specs at http://spacevatican.org/2011/7/3/sporking-with-akephalos

from akephalos.

@fchenung: Good work!

from akephalos.

@fchenung: Excellent Job. Nice write up too.

We should add this to the docs of Spork in the short term.

from akephalos.