moving away from backgroundrb

[nahum]

for lots of reasons, the primary two being memory bloat and how it
effects my deployments - ie having to co-ordinate stopping and
starting it with either passenger or mongrel. not fun and unnecessary
site downtime.

I know there are a bunch of other options, just wondering if there was
anything anyone here wanted to point out as being awesome.


cheers,
nahum

[Nigel Ramsay]

Bj or background job is supposed to be good

[Kieran P]

I've been working with delayed_job recently (in particular the
collectiveidea fork - http://github.com/collectiveidea/delayed_job)

Been very good, very little memory usage, very easy to get started
with.

Regards
Kieran

On Sep 17, 2:09 pm, nahum <nahum.w...@gmail.com> wrote:

[Matt Powell]

I'm happily using delayed_job, as demonstrated here: http://railscasts.com/episodes/171-delayed-job

The syntax is great: #send becomes #send_later, and that's it :)

Check out the rockstar list of authors: http://tobi.github.com/delayed_job/

M

[Nahum Wild]

cool. I didn't know about the rockstars behind delayed_job! :-)

nahum.

[Tim Haines]

Favstar's a bit of a lol in this regard.

I use delayed_job for some tasks, spawn for others, and employ a queue (Starling right now) for others.

I schedule tasks with rufus-scheduler..

Tim.

[Nahum Wild]

with background_job what happen when I restart it on a server if it's
just started running a 20 minute job?

nahum.

[Tim Uckun]

On Thu, Sep 17, 2009 at 3:06 PM, Tim Haines <tmha...@gmail.com> wrote:
> Favstar's a bit of a lol in this regard.
> I use delayed_job for some tasks, spawn for others, and employ a queue
> (Starling right now) for others.
> I schedule tasks with rufus-scheduler..

I wrote my own thing with rufus-scheduler. Nothing on the market did
what I wanted. I am quite happy with it and it was pretty easy to do.

I use it as a combination scheduler and background service. It's
persistent and it puts the result of every run into a database linked
to the schedule linked to the user linked to the cilent.

I used eventmachine for the networking.

[jemmyw]

I've been using spawn for simple things that need to return to the
user immediately - it works great, but it's not very scalable. With
Ruby EE though its pretty manageable.

[Nahum Wild]

I've ended up moving to a combination of spawn and cron. Like you
said it won't scale but its a better situation than what I had, and
I'll find a better one if I need to down the line.

cheers all

nahum.

[jemmyw]

> I've ended up moving to a combination of spawn and cron.  Like you
> said it won't scale but its a better situation than what I had, and
> I'll find a better one if I need to down the line.

I use the same. I'm actually very wary of background processing
programs written in ruby - I've had some bad experiences, so forking
(spawn) and cron have been my good friends. Recently I've been looking
at AMQP solutions such as RabbitMQ with a ruby client as this is
designed to be stable and most importantly not lose messages if the
don't get processed for some reason.

[Tim Uckun]

>
> I use the same. I'm actually very wary of background processing
> programs written in ruby - I've had some bad experiences, so forking
> (spawn) and cron have been my good friends. Recently I've been looking
> at AMQP solutions such as RabbitMQ with a ruby client as this is
> designed to be stable and most importantly not lose messages if the
> don't get processed for some reason.

Since you already have a database why not use that as a queue?

If you are thinking about a server I would also consider using gearman
or even XMPP. I was able to use google apps for domains as a XMPP
server to get a couple of ruby clients talking to each other. Since
google is going to be pushing wave seems like they are going to devote
a lot of resources to it.

[Nahum Wild]

I want to be able to do 'hot' updates to the site, ie not take it down
and not interrupt any existing precesses when I do a release. Spawn
and cron will given me that - spawn forks survive the parent
disappearing, so very important with passenger as well as new
deployments.

In reality using a queue is a bit overkill at presesnt, but I'll be
moving towards RabbitMQ when the time is right.

Cheers,
Nahum.