It sounds to me like the C code is crashing the VM process that BackgroundRB is running in. If this is intermittent then it may be data specific to what you are working with. It sounds like you need to do some additional debugging of the BackgroundRB code being executed. Put in tracing of basic execution paths and input data so you can narrow down where the crashes are happening.
Michael
Following on Michael's suggestion, I'd implore you to make sure your logic is firmly located within the model (or lib), and then write a flurry of tests.
Once you've killed every last bug, then you'll likely have more luck tracking down the problem.
I've only had two problems with Backgroundrb so far that weren't application specific - very short running processes can upset brb, plus I seen 'cannot find slave socket' that will basically halt brb.
Both the above flood background_server.log.
Good tests have the key otherwise.
Jodi
I have the same *exact* problem. The 'ruby' processes don't die, MiddleMan's jobs.keys still has the key I passed, yet, execution stops.
I've narrowed the problem to one of my models, where I do:
self.connection.execute(sql_string)
Changing self.connection to ActiveRecord::Base.connection doesn't fix it, disabling the enable_concurrency = true inside the Rails worker class doesn't fix it either.
It's very puzzling.
Micahel,
can you post your worker code?
otherwise, I'd separate the possibilities by running that exact code inside a simple .rb script - with a loop and sleep.
a thought: does do_work have a self.delete ?
Cheers, Jodi General Partner The nNovation Group inc. www.nnovation.ca/blog
Michael - I don't see a self.delete
Plus it's possible your rescue is firing an exception. I suggest you output text that can't crash - then introduce vars slowly
Jodi