Backgroundrb devel - Nov 2008 - Get a unique job id back when enqueing a task

This is a simple question, but i can''t find the answer on the
internets.  Is
there a way, when putting a job into the job queue, to get back an object
for the BdrbJobQueue record that is created?  (or at least its id)

I need to pass a simple id around my app that will always relate to a
specific job.  At the moment i''m doing this by making a unique job key
string and using that to create and track the job, but it''s a clumsy
approach and i''d rather just use the id from the db table, which i
would
pull from the new job object.  Assuming i can get it back.

Thanks for the help, bdrbheads.  ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20081120/01b927c3/attachment.html>

Yes!

You can use job_key method in your worker to retrieve the job key of
current task. Its a thread local variable and hence thread safe, can
be also used inside threads without problems.

You can also use persistent_job method inside your worker to retrieve
currently executed task.

On Thu, Nov 20, 2008 at 3:59 PM, Max Williams
<toastkid.williams at gmail.com> wrote:
> This is a simple question, but i can''t find the answer on the
internets.  Is
> there a way, when putting a job into the job queue, to get back an object
> for the BdrbJobQueue record that is created?  (or at least its id)
>
> I need to pass a simple id around my app that will always relate to a
> specific job.  At the moment i''m doing this by making a unique job
key
> string and using that to create and track the job, but it''s a
clumsy
> approach and i''d rather just use the id from the db table, which i
would
> pull from the new job object.  Assuming i can get it back.
>
> Thanks for the help, bdrbheads.  ;-)
>
>
>
> _______________________________________________
> 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

Thanks Hemant.  My problem is though that i need to know a unique id for a
job before it is picked up by a worker (so i can start tracking it).

What would be perfect is to get the id of the job queue record: at the
moment that''s what i''m doing but in quite a clumsy way.  Is
there a way to
just get the actual BdrbJobQueue object back?

max

2008/11/20 hemant <gethemant at gmail.com>
> Yes!
>
> You can use job_key method in your worker to retrieve the job key of
> current task. Its a thread local variable and hence thread safe, can
> be also used inside threads without problems.
>
> You can also use persistent_job method inside your worker to retrieve
> currently executed task.
>
> On Thu, Nov 20, 2008 at 3:59 PM, Max Williams
> <toastkid.williams at gmail.com> wrote:
> > This is a simple question, but i can''t find the answer on the
internets.
>  Is
> > there a way, when putting a job into the job queue, to get back an
object
> > for the BdrbJobQueue record that is created?  (or at least its id)
> >
> > I need to pass a simple id around my app that will always relate to a
> > specific job.  At the moment i''m doing this by making a
unique job key
> > string and using that to create and track the job, but it''s a
clumsy
> > approach and i''d rather just use the id from the db table,
which i would
> > pull from the new job object.  Assuming i can get it back.
> >
> > Thanks for the help, bdrbheads.  ;-)
> >
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20081120/c9317167/attachment-0001.html>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20081120/572cc8d9/attachment.html>

Never mind, i fixed server-testing problem, i was being a dumbass.  I''d
still like to know about the job ids though...

2008/11/20 Max Williams <toastkid.williams at gmail.com>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20081120/4caaba3d/attachment.html>

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20081120/537f6c9f/attachment.html>

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

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>