Hi,
it would be nice to be able to specify workers as singletons. By this
I mean that every call to the new_worker method returns the same
instance of said worker. This can be done transparently either by
adding a new argument to new_worker (something like :singleton =>
true) or adding a new method, like I did in my installation of
BackgrounDrb:
def get_worker_by_class(klass)
klasse =
klass.to_s.split(''_'').inject('''') {
|total,part| total
<< part.capitalize }
@jobs.each do |e|
@logger.debug e.inspect
if e[1].class.name == klasse
return e[0]
end
end
return nil
end
def new_singleton_worker(opts={})
@mutex.synchronize {
worker = get_worker_by_class(opts[:class])
if worker.nil?
job_key = opts[:job_key] || gen_key
unless self[job_key]
self[job_key] = instantiate_worker(opts[:class]).new(opts
[:args])
return job_key
else
raise "job_key: #{job_key} already refers to a running
worker"
end
else
return worker
end
}
end
First the jobs array is checked if an instance of the requested
worker class is already available. If yes, it''s returned otherwise a
new instance is created using the standard instantiate_worker method.
Could you include something like this in the next version?
G?nter
On Jul 3, 2006, at 8:28 AM, G?nter Ladwig wrote:> Hi, > > it would be nice to be able to specify workers as singletons. By this > I mean that every call to the new_worker method returns the same > instance of said worker. This can be done transparently either by > adding a new argument to new_worker (something like :singleton => > true) or adding a new method, like I did in my installation of > BackgrounDrb: > > def get_worker_by_class(klass) > klasse = klass.to_s.split(''_'').inject('''') { |total,part| total > << part.capitalize } > @jobs.each do |e| > @logger.debug e.inspect > if e[1].class.name == klasse > return e[0] > end > end > return nil > end > > def new_singleton_worker(opts={}) > @mutex.synchronize { > worker = get_worker_by_class(opts[:class]) > if worker.nil? > job_key = opts[:job_key] || gen_key > unless self[job_key] > self[job_key] = instantiate_worker(opts[:class]).new(opts > [:args]) > return job_key > else > raise "job_key: #{job_key} already refers to a running > worker" > end > else > return worker > end > } > end > > First the jobs array is checked if an instance of the requested > worker class is already available. If yes, it''s returned otherwise a > new instance is created using the standard instantiate_worker method. > > Could you include something like this in the next version? > > G?nterHi Gunter- I can add a singleton type worker probably. Can you tell me what your use case is for needing this? I''m curious as to how you would use or what you plan on doing with singleton workers. Are you defining your worker classes as actual singletons using include Singleton? If so then maybe I can make a different type of superclass to inherit your workers from that is a true singleton. I''ll have to think about it a bit. I just added new job management stuff to the threading model so I will have to work that in with your singleton idea but I''m sure I can come up with a nice way of doing this for you. Cheers- -Ezra
On 03.07.2006, at 22:19, Ezra Zygmuntowicz wrote:> > Hi Gunter- > > I can add a singleton type worker probably. Can you tell me what > your use case is for needing this? I''m curious as to how you would > use or what you plan on doing with singleton workers. Are you > defining your worker classes as actual singletons using include > Singleton? If so then maybe I can make a different type of > superclass to inherit your workers from that is a true singleton. > I''ll have to think about it a bit. I just added new job management > stuff to the threading model so I will have to work that in with > your singleton idea but I''m sure I can come up with a nice way of > doing this for you.No, the worker class is not defined as a Singleton. It''s just that I need only one instance of the worker. I''m not using the worker for temporary background calculations (which seems to be the common use case), but instead as a background process that periodically updates the database and takes requests from the Rails app. It should not be killed and respawned because it has persistent connections to other servers. G?nter
On Jul 3, 2006, at 2:45 PM, G?nter Ladwig wrote:> > On 03.07.2006, at 22:19, Ezra Zygmuntowicz wrote: > >> >> Hi Gunter- >> >> I can add a singleton type worker probably. Can you tell me what >> your use case is for needing this? I''m curious as to how you would >> use or what you plan on doing with singleton workers. Are you >> defining your worker classes as actual singletons using include >> Singleton? If so then maybe I can make a different type of >> superclass to inherit your workers from that is a true singleton. >> I''ll have to think about it a bit. I just added new job management >> stuff to the threading model so I will have to work that in with >> your singleton idea but I''m sure I can come up with a nice way of >> doing this for you. > > No, the worker class is not defined as a Singleton. It''s just that I > need only one instance of the worker. I''m not using the worker for > temporary background calculations (which seems to be the common use > case), but instead as a background process that periodically updates > the database and takes requests from the Rails app. It should not be > killed and respawned because it has persistent connections to other > servers. > > G?nterGunter- OK I see what you want to do. I will come up with a way to do that for you. I also just changed things so that if you don''t specify a :ttl param when you do new_worker then your worker will become :immortal. The only way to delete an immortal worker is by calling gc! or using delete_worker directly. Cheers- -Ezra
On 04.07.2006, at 00:28, Ezra Zygmuntowicz wrote:> > Gunter- > > OK I see what you want to do. I will come up with a way to do that > for you. I also just changed things so that if you don''t specify > a :ttl param when you do new_worker then your worker will > become :immortal. The only way to delete an immortal worker is by > calling gc! or using delete_worker directly.Thanks! I just thought of another "bug" which caused me some headaches: Apparently, on Macs (I''m using an iBook) the DRb server needs to be started like this: DRb.start_service(''druby://localhost:0'') instead of just DRb.start_service Don''t ask me why, I found the solution to this problem here: http://rubyforge.org/pipermail/bdrg-members/2006-May/000043.html G?nter
Hi Ezra, On Jul 3, 2006, at 6:38 PM, G?nter Ladwig wrote:> > On 04.07.2006, at 00:28, Ezra Zygmuntowicz wrote: > >> >> Gunter- >> >> OK I see what you want to do. I will come up with a way to do that >> for you. I also just changed things so that if you don''t specify >> a :ttl param when you do new_worker then your worker will >> become :immortal. The only way to delete an immortal worker is by >> calling gc! or using delete_worker directly. > > Thanks!I have a similar situation to G?nter, so... Thanks from me too. Cheers, Bob> > G?nter > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel---- Bob Hutchison -- blogs at <http://www.recursive.ca/ hutch/> Recursive Design Inc. -- <http://www.recursive.ca/> Raconteur -- <http://www.raconteur.info/> xampl for Ruby -- <http://rubyforge.org/projects/xampl/>
I am looking to use Rails to manage an application. More specifically, I am looking to start/stop and change parameters of my application through a webpage built in Rails, and I am looking to backgroundrb workers to be the application classes. So, +1 for Gunter''s use case! Thanks, David G?nter Ladwig wrote:>On 03.07.2006, at 22:19, Ezra Zygmuntowicz wrote: > > > >>Hi Gunter- >> >> I can add a singleton type worker probably. Can you tell me what >>your use case is for needing this? I''m curious as to how you would >>use or what you plan on doing with singleton workers. Are you >>defining your worker classes as actual singletons using include >>Singleton? If so then maybe I can make a different type of >>superclass to inherit your workers from that is a true singleton. >>I''ll have to think about it a bit. I just added new job management >>stuff to the threading model so I will have to work that in with >>your singleton idea but I''m sure I can come up with a nice way of >>doing this for you. >> >> > >No, the worker class is not defined as a Singleton. It''s just that I >need only one instance of the worker. I''m not using the worker for >temporary background calculations (which seems to be the common use >case), but instead as a background process that periodically updates >the database and takes requests from the Rails app. It should not be >killed and respawned because it has persistent connections to other >servers. > >G?nter > >_______________________________________________ >Backgroundrb-devel mailing list >Backgroundrb-devel at rubyforge.org >http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > >