HI Warren, Thanks for the feedback. From what I understand delayed_job puts in a job in a queue with the assumption that the apps that created the job is the same rails apps that is going to consume the queue. CMIIW. My problem is the queue is created by another external system that is non-rails. At this point I want to evaluate bluepill and see how it fits.
Cheers, Josh. On Wed, Oct 13, 2010 at 11:40 AM, Warren Seen <[email protected]> wrote: > Perhaps I wasn't entirely clear. > I'm not suggesting just sticking the polling of the queue into DJ, I'm > suggesting replacing it entirely. > Instead of putting data into the queue to begin with, all you do is make a > call with send_later. You then get rid of a whole bunch of queue management > code you need to test and maintain, and get back to what I understand is the > crux of the problem... offloading a long-running task into the > background.The tradeoff to the DJ overhead is not having to manage the work > queue. > (Sidenote: We're talking about rails... isn't it a bit late to start > worrying about overhead NOW? :D) > > For an inexperienced developer (The subject does say [noob]), implementing > your own job queue (unless you can clearly describe why existing queues > don't meet your needs) is not a matter of taste, it's a code smell. > > Cheers, > Warren > On 13/10/2010, at 11:17 AM, Ivan Vanderbyl wrote: > > Disagree, at the core of it he is doing exactly what delayed_job does to > look for jobs (polls database every 5 seconds), except if using delayed job > he would then have that overhead. Sure there is no reason why you couldn't > use delayed job and reschedule the job after each run. > However delayed job like any background task has the possibility of > crashing, which then brings you back to something like bluepill to restart > your workers. > Matter of taste. > Ivan > On 13/10/2010, at 11:11 AM, Warren Seen wrote: > > Seriously? > IMO, it's overkill to write your own jobs queue management, plus a worker, > rather than just using delayed_job's queue and worker - or any other lib for > that matter. > Anything else is reinventing the wheel, only your wheel probably ends up > being an octagon or something less than round... > > On 13/10/2010, at 10:51 AM, Ivan Vanderbyl wrote: > > Hi Josh, > This is a problem I had recently. Using Resque would probably be overkill, > as would delayed_job. > From what I gather you want to keep this script running in the background? > What I would do is use something like bluepill > (http://github.com/ivanvanderbyl/bluepill) and set it to daemonize your > script, which could be a rake task as it would then be able to load up your > entire rails stack (once) and have access to all your models etc. > Ivan > On 13/10/2010, at 10:42 AM, Joshua Partogi wrote: > > Hi all, > > I have another noobie question. After looking at last night > presentation about Rails 3, I am wondering where do we put piece of > code that runs on a separate thread for a long time every 5 seconds? > e.g > > Thread.new do > while true > queue = check_whether_there_is_something_new_in_the_queue > > while queue > 0 > Trends.create(:data => queue.data) > end > > sleep 5 > end > end > > > 1. I don't really like using cron to call `script/rails runner` as > that will load the whole rails library which will choke the server > because this process is run every 5 seconds. > 2. I don't know about resque (which was mentioned by Ryan) yet, but > since resque is a separate webapp, would resque know anything about > the models in my Rails app? > > > Any input is highly appreciated. > > Kind regards, > Josh > > -- > http://twitter.com/scrum8 > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- http://twitter.com/scrum8 -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
