Can someone PLEASE help me. BackgroundRB doesn’t finish its process, nor
does it log any errors, even if I place the section of code,
initializing a new Photo object, within a begin / rescue block. Nothing
happens short of the process dying, leaving me with temp files and
backgroundrbunix files in my ///tmp folder. What is going on here? I’m
not near my memory cap, and sometimes it works… so it can’t just be a
code issue thats erroring out all the time. Can someone please shed some
light on this for me? Thanks.
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
On Jun 4, 4:55 pm, Bryan C. [email protected]
On 4-Jun-07, at 8:18 PM, MichaelLatta wrote:
not near my memory cap, and sometimes it works… so it can’t just
be a
code issue thats erroring out all the time. Can someone please
shed some
light on this for me? Thanks.–
Posted viahttp://www.ruby-forum.com/.
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
Bryan C. wrote:
Jodi S. wrote:
On 4-Jun-07, at 8:18 PM, MichaelLatta wrote:
not near my memory cap, and sometimes it works… so it can’t just
be a
code issue thats erroring out all the time. Can someone please
shed some
light on this for me? Thanks.–
Posted viahttp://www.ruby-forum.com/.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
Jodi and Michael…
The thing is I am using the same exact input for both the failing and
passing executions, so the intermittentcy really worries me. I guess
I’ll write all the tests and whatnot for everything I can possibly think
of and go from there, but I don’t understand why consistently the first
attempt will always fail using backgroundrb but then following attempts
within a few minutes work just fine. I also don’t understand why my code
doesn’t throw any errors in development mode locally and works
flawlessly every time.
Also, it always fails when I do Photo.new in my backgroundrb worker
code. Always the same input, sometimes it works, sometimes it seems like
it times-out or something. I put it in a begin / rescue block and never
get the rescue code to run so another reason I don’t think it’s an
exception causing my issues.
On Jun 4, 2007, at 8:44 PM, Jodi S. wrote:
On 4-Jun-07, at 8:18 PM, MichaelLatta wrote:
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.
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.
–
Jordi
On 5-Jun-07, at 12:13 PM, Bryan C. wrote:
light on this for me? Thanks.
Jodi and Michael…
my code
exception causing my issues.
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
Jodi S. wrote:
On 5-Jun-07, at 12:13 PM, Bryan C. wrote:
light on this for me? Thanks.
Jodi and Michael…
my code
exception causing my issues.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
Update for you guys. Just before the processes die they go into a D
state. I have setup a begin / rescue clause around the Photo.new method
as listed below, but nothing ever gets logged, which leads me to believe
I am hitting some sort of other failure, or some time-out or something.
begin
logger.info(“PhotoProcessorWorker do work – #{self.jobkey} |
#{user.login} | Initialized New Photo”) if photo =
Photo.new(photoparams)
rescue Exception => prob
logger.info(“PhotoProcessorWorker do work – #{self.jobkey} |
#{user.login} | #{prob.inspect}”)
end
On 5-Jun-07, at 2:47 PM, Bryan C. wrote:
Cheers,
believe
end–
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
Jodi S. wrote:
On 4-Jun-07, at 8:18 PM, MichaelLatta wrote:
not near my memory cap, and sometimes it works… so it can’t just
be a
code issue thats erroring out all the time. Can someone please
shed some
light on this for me? Thanks.–
Posted viahttp://www.ruby-forum.com/.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
Jodi and Michael…
The thing is I am using the same exact input for both the failing and
passing executions, so the intermittentcy really worries me. I guess
I’ll write all the tests and whatnot for everything I can possibly think
of and go from there, but I don’t understand why consistently the first
attempt will always fail using backgroundrb but then following attempts
within a few minutes work just fine. I also don’t understand why my code
doesn’t throw any errors in development mode locally and works
flawlessly every time.