I’m looking for recommendations for a simple, stable way to accomplish
this.
Here’s the scenario:
- whenever a user visits my app, I need to fire off a method that
launches some API calls.
- the user sees a ‘loading’ screen until the method returns some 15-20
seconds later.
I’ve installed BackgrounDRB and am running it with thread pooling. This
works, but the job server crashes after a little while (I don’t know how
many concurrent threads each worker is supposed to handle…)
I’m looking for a solution that’s as simple, lightweight and stable as
possible for what I need to do. Ideally it wouldn’t involve monitoring a
separate process.
Right now I’m debating between:
- trying to fix BackgrounDRb
- installing Backgroundjob, which is self-spawning and hopefully more
reliable
- using spawn, either with forking or threading
What kind of setup would you run?
Robert M. wrote:
Right now I’m debating between:
- trying to fix BackgrounDRb
- installing Backgroundjob, which is self-spawning and hopefully more
reliable
- using spawn, either with forking or threading
Well, it appears none of my alternatives would even work…
- Spawn with forking doesn’t seem to work under Passenger
- Spawn with threading doesn’t either (apparently need another Apache or
something?)
- Backgroundjob doesn’t seem to have any provisions for running
concurrent tasks…
Any ideas?
On Oct 14, 2:07 pm, swachian [email protected] wrote:
I have such a problem as well. Spawn forks well in mongrel, but fails
in passenger.
However, it can be run spawn in thread mode if you have set the
config.active_record.allow_concurrency=true .
Something “stupid” like system(“…”) might work (because that’s both
forking and execing)
Fred
I have such a problem as well. Spawn forks well in mongrel, but fails
in passenger.
However, it can be run spawn in thread mode if you have set the
config.active_record.allow_concurrency=true .
On Sep 16, 2:51 am, Robert M. [email protected]
the active_record connection seems to be broken if only use normal
fork
On Oct 14, 10:08 pm, Frederick C. [email protected]