0

I have need to periodically run a background task in my rails app. I've done some research and it seems that there is not a standard way to do this.

I don't want to generate a new app context so a runner seems to be out of the question. I'd prefer not to run my own thread handler if I don't have to. (It looks like this may be the most promising option at this point other than the below).

Using the whenever gem I am doing the following in schedule.rb:

every 15.minutes do
    command "curl http://127.0.0.1:3000/periodic"
end

This feels a little like a hack, but I can't find anything that is more straightforward than this -- Everything else I can find seems like a lot of effort for something seemingly basic.

I should note that this is an internal project and will be behind a firewall, and headless automated middleware, so there is low expectation that a user will ever be accessing this project directly.

Am I missing something or is background processing or timed events really just not supported out of the box with rails?

slycrel
  • 4,275
  • 2
  • 30
  • 30
  • possible duplicate of [A cron job for rails: best practices?](http://stackoverflow.com/questions/285717/a-cron-job-for-rails-best-practices) (read all answers, not just the accepted - in particular, the second one, which is highest-ranked) – Amadan Dec 12 '12 at 01:51
  • Thanks amadan. The second one is what I specifically don't want -- For the entire environment to be reloaded every time this happens. I am already using whenever, am I missing something else obvious? This question has been downvoted twice, rather than a down vote it would be nice to have more helpful responses. Even if I look like an ignoramus, I'm okay with that -- I genuinely don't know. =) – slycrel Dec 12 '12 at 05:54
  • Please read http://meta.stackexchange.com/questions/32490/closing-migrating-question-instructions-guidance/32515#32515 . A close vote is *not* a downvote. It is a mechanism to close questions that will not be answered due to various reasons - some good, some bad. There is no shame in being closed as a duplicate question - it's a good question, but with StackOverflow volume it makes no sense answering the same thing over and over. On the other hand, close due to "not a real question" indicates you asked something... well, dumb, or the question is not written well enough. Downvotes are different – Amadan Dec 12 '12 at 06:04
  • Thanks for the clarification Amadan. Your linked SO question (even the second answer) doesn't really get me where I want to be, as far as I understand it. I don't want to effectively restart my rails app when this gets called -- I want to keep my current context. Am I misunderstanding how this works? – slycrel Dec 12 '12 at 06:14
  • Hmm, I missed that part. I guess you could make an `after_initialize` [railtie](http://andre.arko.net/2010/10/15/extending-rails-3-with-railties/), and launch a thread there... – Amadan Dec 12 '12 at 06:32

1 Answers1

0

After some research, Amadan's suggestion of a railtie may get me what I want here. As an ideal solution it isn't perfect, though depending on the context (i.e. a publicly accessible rails project) this is the way to go. For the project I am working on it's a little heavy handed, as I'm doing a rails app that is a bridge between two systems, running headless, with no user input behind a firewall.

slycrel
  • 4,275
  • 2
  • 30
  • 30