yes - I know - I use DJ presently
my question was about what advantages you see with clockwork over cron -
other than syntax I don't see any advantages
now if the schedule was stored in the db, and I could run multiple
clockworks on each server there would some inherent scheduling failover (DJ
already provides job/worker failover)
On Sat, Mar 23, 2013 at 5:37 PM, tamouse mailing lists <
tamouse.li...@gmail.com> wrote:
> On Sat, Mar 23, 2013 at 1:20 PM, Jodi Showers <j...@homestars.com> wrote:
> > I'm just about to scale to a second app server - so good timing
> >
> > in which ways did you find cron to be a poor choice ? on a single server
> > they meet our needs nicely
> >
> > you'd only run one clock instance per cluster - so much like cron (ie. no
> > interserver clock scheduling). Have you tried using clock driven from a
> > schedule described in the db (like a centralized cron, useful for
> failover)
> > ?
> >
> > Any thoughts you have on this topic appreciated
> >
> > As for the OP, I hope they can see the short and long term options before
> > them.
> >
> > J
> >
> >
> >
> >
> > On Sat, Mar 23, 2013 at 2:01 PM, tamouse mailing lists
> > <tamouse.li...@gmail.com> wrote:
> >>
> >> Please bottom post (appending). It makes responses easier to find.
> >>
> >> On Sat, Mar 23, 2013 at 10:32 AM, Jodi Showers <j...@homestars.com>
> wrote:
> >> > that is a good thinking, just like normalization - then comes a time
> to
> >> > denormalize
> >> >
> >> > we have millions of visitors per month - and about 50 asynch
> processes -
> >> > having one rails process deal with all those asynchs rather than one
> per
> >> > is
> >> > not helpful in any way
> >> >
> >> > using a best practice such as my approach is not harder to implement
> and
> >> > will scale - choosing an approach of equal complexity that won't scale
> >> > doesn't hold water
> >> >
> >> >
> >> > On Sat, Mar 23, 2013 at 11:27 AM, Colin Law <clan...@googlemail.com>
> >> > wrote:
> >> >>
> >> >> On 23 March 2013 15:15, Jodi Showers <j...@homestars.com> wrote:
> >> >> > for regularly scheduled jobs, I use a mixture of cron (to create a
> >> >> > delayed
> >> >> > job), and the delayed_job itself
> >> >> >
> >> >> > the crontab instance is very light, just a small (non-rails) rb
> >> >> > script
> >> >> > to
> >> >> > insert the delayed_job in the delayed_jobs table
> >> >> >
> >> >> > then the delayed_job instance will pickup the job and run it
> >> >> >
> >> >> > in your instance, I would create a class method on the Test model -
> >> >> > something like
> >> >> >
> >> >> > def self.remove_old_unpublished
> >> >> > delete_all(["created_at < ? and state in('unpublished')",
> >> >> > 24.hours.ago])
> >> >> > end
> >> >> >
> >> >> > cron entry like this:
> >> >> > 05 1 * * * cd /path/to/current && RAILS_ENV=production
> >> >> > /path/to/current/lib/delayed_job_cron_jobs/create_delayed_job.rb
> >> >> > --model
> >> >> > "Test" --method "remove_old_unpublished" --queue "general"
> >> >> > --arguments
> >> >> > "{:any_argument => 42}"
> >> >> >
> >> >> > the following gist is a script to insert delayed_jobs from cron
> >> >> > https://gist.github.com/jshow/5228049
> >> >> >
> >> >> > fyi, the reason to take this route over the simpler rake route (run
> >> >> > rake
> >> >> > task from cron) is performance and memory usage - this method will
> >> >> > save
> >> >> > you
> >> >> > a bunch of both.
> >> >>
> >> >> I am always suspicious of the idea of doing something in a more
> >> >> complex way in order to save resources. It is only worth spending
> the
> >> >> additional time developing the solution if computing resources are
> >> >> likely to be an issue. Computing resources are usually cheaper than
> >> >> human resources.
> >> >>
> >> >> Colin
> >> >>
> >> >> --
> >> >> You received this message because you are subscribed to the Google
> >> >> Groups
> >> >> "Ruby on Rails: Talk" group.
> >> >> To unsubscribe from this group and stop receiving emails from it,
> send
> >> >> an
> >> >> email to rubyonrails-talk+unsubscr...@googlegroups.com.
> >> >> To post to this group, send email to
> rubyonrails-talk@googlegroups.com.
> >> >> For more options, visit https://groups.google.com/groups/opt_out.
> >> >>
> >> >>
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups
> >> > "Ruby on Rails: Talk" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send
> >> > an
> >> > email to rubyonrails-talk+unsubscr...@googlegroups.com.
> >> > To post to this group, send email to
> rubyonrails-talk@googlegroups.com.
> >> > For more options, visit https://groups.google.com/groups/opt_out.
> >> >
> >> >
> >>
> >> If you're working in a distributed, multi-server and multi-process
> >> environment, cron is a poor solution. DelayedJobs and several others
> >> work in a distributed environment much better. I have been using the
> >> gem clockwork in addition to DJ, which makes things very simple.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Ruby on Rails: Talk" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to rubyonrails-talk+unsubscr...@googlegroups.com.
> >> To post to this group, send email to rubyonrails-talk@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Ruby on Rails: Talk" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to rubyonrails-talk+unsubscr...@googlegroups.com.
> > To post to this group, send email to rubyonrails-talk@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> The primary issue when you bring in multiple servers is
> synchronization of the workers. Cron can't do that, as it only knows
> about one server. Having something that workers can distribute over
> requires something more sophisticated. That's what DJ is really about.
> Using clockwork makes it all the easier coming from cron.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-talk+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-talk@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
