On Mon, Mar 8, 2010 at 22:19, Chris McCann <[email protected]> wrote:
> With DJ I tried caching a :percent_complete value but it seems the > delayed_job process and Rails don't share the same memory space. The > value cached by DJ is always null when read by the Rails controller. > Would using the mem_cache store solve that? > The basic idea here is that it is up to your job itself to report its progress. Memcache is indeed a great way to solve this. (By default you're using the memory store, which is per-process.) Another approach would be to use some known object in the database that you can update from within your job. The real trick is having a natural identifier that lets you bridge the gap between reporting and querying for progress. The easiest way to accomplish this would be to make sure your job is being called as the instance method of some object that exists in the database. You could then update that record in stages, record progress as you go, and have your "waiting" page poll that object for updates. Perhaps that approach already fits your problem, in which case you're good to go. If not, I would even advise you consider creating a light wrapper object whose purpose is to invoke the work and track its progress. This would actually be a lot easier if you had access to the id of the actual Job object. Then you could add a progress column to that table and update it directly. Unfortunately, after a quick read through the docs and code, it doesn't seem like that's readily available. Perhaps a patch is in order – I'd love to be able to call something like Delayed::Job.current.progress = .5… Anyway, let us know how it goes. I'd be curious to hear what you end up implementing. -- Nick Zadrozny -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
