[Backgroundrb-devel] Get a unique job id back when enqueing a task

Max Williams toastkid.williams at gmail.com
Fri Nov 21 04:25:07 EST 2008


I have this situation, maybe i'm not dealing with it very cleverly, but here
goes.

We have lessons that can be zipped up and downloaded by the user.  We use
backgroundrb to do the zipping up since it's quite cpu intensive and the
queueing system means that only one can be done at once, and our mongrels
don't get tied up with it (which they didn't like very much).

So, i shove a job into the zipping up queue, then open a lightbox style
window that checks with ajax every five seconds to see if the job has been
finished yet.  If it has then it triggers the download of the zip file.

The same user could download the same lesson many times, so i need some way
to tell these jobs apart.  At the moment i'm doing something horrible with
the current time, lesson id and user id to generate a unique key, and using
that key to search for the BdrbJobQueue object, getting the id and then
passing that through to my view page for the ajax method to use to see if
it's finished.  I can't rely on getting anything from the worker, because i
need to start tracking the job request as soon as it goes into the queue.
So, i can't wait for a worker to do anything with persistent job.

Do you see what i mean?  Am i going about this in a dumb way?

thanks for your time :)
max

2008/11/21 hemant <gethemant at gmail.com>

> I am afraid, I do not follow you. You said you wanted actual
> BdrbJobQueue object back, persistent_job returns exactly the same, but
> from within the worker. It will always return the job that has been
> just started. If you want to know the status of a task from outside,
> using MiddleMan proxy, then you can use job_key for that purpose. But,
> I am assuming, since user is setting the job_key himself, when he
> submits a task, he does know about the job key that he submitted,
> right?
>
>
>
> On Thu, Nov 20, 2008 at 9:52 PM, Max Williams
> <toastkid.williams at gmail.com> wrote:
> > Don't i have the same problem with persistent_job though?  If
> persistent_job
> > is the currently running queued task, then when i put the job into the
> > queue, the worker hasn't started it and so the job doesn't exist - right?
> > Or, can MiddleMan get it back somehow?  I guess i'm talking about a job
> > request (which is what the db table holds) rather than the actual job.
> >
> > As for testing if the server is connected properly, I monkey_patched my
> own
> > method :)  Quick and dirty, probably doesn't work in all situations but
> > suits my needs:
> >
> > module BackgrounDRb
> >
> >   class Config
> >     #returns socket for current environment eg "0.0.0.0:11006"
> >     def self.socket_string
> >
> >
> "#{BDRB_CONFIG[:backgroundrb][:ip]}:#{BDRB_CONFIG[RAILS_ENV.to_sym][:backgroundrb][:port]}"
> >     end
> >   end
> >
> >   class ClusterConnection
> >     #call on MiddleMan
> >     def connected_to_server?
> >       self.all_worker_info[BackgrounDRb::Config.socket_string] != nil
> >     end
> >   end
> >
> > end
> >
> > thanks, max
> >
> > 2008/11/20 hemant <gethemant at gmail.com>
> >>
> >> The object returned by "persistent_job" method is an instance
> >> BdrbJobQueue class.
> >> Also, currently there is no API method to check if server is running.
> >> I am afraid, you will have to hack your own or wait for next release.
> >>
> >>
> >>
> >>
> >> On Thu, Nov 20, 2008 at 7:56 PM, Max Williams
> >> <toastkid.williams at gmail.com> wrote:
> >> > Another dumb question...
> >> >
> >> > Before i enqueue a job, I want to raise an exception if the Bdrb
> server
> >> > isn't running.  Is there  a quick and easy way to test for this?  I
> >> > thought
> >> > i'd seen a method somewhere but i've been hunting round various docs
> and
> >> > the
> >> > code and can't find a way.  I might just be being blind though.
> >> >
> >> > thanks, max
> >> >
> >> > _______________________________________________
> >> > Backgroundrb-devel mailing list
> >> > Backgroundrb-devel at rubyforge.org
> >> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >> >
> >>
> >>
> >>
> >> --
> >> Let them talk of their oriental summer climes of everlasting
> >> conservatories; give me the privilege of making my own summer with my
> >> own coals.
> >>
> >> http://gnufied.org
> >
> >
>
>
>
> --
> Let them talk of their oriental summer climes of everlasting
> conservatories; give me the privilege of making my own summer with my
> own coals.
>
> http://gnufied.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20081121/e614bc37/attachment-0001.html>


More information about the Backgroundrb-devel mailing list