From ron.miles at 1000paces.com Fri Oct 12 17:17:55 2007 From: ron.miles at 1000paces.com (Ron Miles) Date: Fri, 12 Oct 2007 17:17:55 -0400 Subject: [Backgroundrb-devel] Trouble on Multi Server setup Message-ID: Hello all, I'm having some trouble getting backgroundrb set up so that all the processing happens on a single machine. I have 3 load balanced machines. Right now, all three run our web application and create MiddleMan workers to generate a large PDF report. However, because of the processing power needed to generate the PDFs, I want to change our setup so that two servers run Apache/Mongrel serving our web application. The third would handle a number of other tasks, including report generation. I found this thread, but I can't get it to work: http://rubyforge.org/pipermail/backgroundrb-devel/2006-December/000576.html In my setup, server1 will be the report server, and server2 and server3 are the application/web servers The backgroundrb.yml looks like this on servers 2 and 3: port: 22223 timer-sleep: 60 load_rails: true rails_env: production environment: production host: 172.16.0.1 database_yml: config/database.yml pool_size: 10 (172.16.0.1 is the local IP for server1) On the report server (server1), I have this: port: 22223 timer-sleep: 60 load_rails: true rails_env: production environment: production host: localhost database_yml: config/database.yml pool_size: 10 protocal: druby :deny: all :allow: localhost 127.0.0.1 172.16.0.1 172.16.0.2 :order: deny,allow I tried commenting out "self.setup_drb_acl" in lib/backgroundrb_server.rb, but it didn't make any difference. Also, if I run "MiddleMan.jobs" from ./script/console on server2 or server3, I get this: # >From server1, I get this: # This **seems** right, since the correct port and host are there. I'm suspicious about drbunix vs. druby though. If change the protocol to druby, I get connection refused errors. DRb::DRbConnError: druby://172.16.0.3:22223 - # As it I have it set up right now, all the logging appears on the web server that accepted the request (both in backgroundrb.log and production.log). It seems like at least some of this should be offloaded to the report server. Also, if I run top on the web server, I get 50+% processor usage when I click the link in the app to start the process. So I'm stumped. Can anyone give me any pointers? I'm not very familiar with the technology backgroundrb is based on, so I apologize if I'm missing something obvious. Thanks in advance for any help BTW, I'm using ruby 1.8.5, rails 1.2.2 and the latest backgroundrb. -Ron From bill.walton at charter.net Wed Oct 24 09:20:41 2007 From: bill.walton at charter.net (Bill Walton) Date: Wed, 24 Oct 2007 09:20:41 -0400 Subject: [Backgroundrb-devel] Need advice - which version to use? Message-ID: <011701c81640$acf40390$6401a8c0@Precision670> Greetings! I could use some advice on which version of BackgrounDrb to use in my current situation. I've implemented the initial, single-process multi-threaded version in a previous site, but have no experience with the new version. Current situation is as follows. The application involves personal health information and so has very stringent session management requirements. My question derives from the need to reset the session (to require re-login) when the visitor closes their browser. Current thought-process is to use periodically_call_remote to set a session variable that can be checked by a worker to determine whether or not the browser is still there. Anybody got any thoughts to share on the pros and cons of either version of BackgrounDrb for this? Thanks in advance, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20071024/882285fb/attachment.html From gethemant at gmail.com Wed Oct 24 09:56:58 2007 From: gethemant at gmail.com (hemant) Date: Wed, 24 Oct 2007 19:26:58 +0530 Subject: [Backgroundrb-devel] Couple questions about backgroundrb In-Reply-To: References: Message-ID: On 9/28/07, Joe Van Dyk wrote: > So, If I want to set up multiple running processes that do stuff, do I > use the MiddleMan stuff? The documents are confusing me. What should > the worker classes inherit from if they need to access rails models? > > On 9/28/07, Eric Pugh wrote: > > I agree with the -1 of cron.. it is a slippery slope.. You think > > "Oh, I'll just cron this one job", and before you know it you have 5 > > or 10 of them.. And no way to monitor them from the webapp... So > > you start communicating via database tables.. > > > > And then you deploy on a new server, and forget to check the crontab > > because it's under some sort of special user account! BackgroundRB > > is much better.. > > > > But I agree that it needs another release.. I have a version that > > isn't trunk latest that works great for me, but when I tried trunk I > > had lots of errors so went back to what worked. Joe, I can zip it > > and send it to you.. Not sure what "version" of backgroundrb it is > > though... > > I was avoiding to count my chickens before they hatch, but I am working on a version of BackgroundDrb which doesn't uses drb altogether. I am running couple of my own workers and its working pretty solid. Although its a bit rough around the edges and doesn't offer some of the functionality that BackgroundDrb has (i hope to implement them in time), but my idea was to have absolutely solid workers. No crash, no logging problems, no corrupt result hashes and no timer misses. Please wait till this weekend. PS: I am the current maintainer of BackgroundDrb. > > Eric > > > > > > > > On Sep 28, 2007, at 12:38 PM, Joe Van Dyk wrote: > > > > > cron only runs once a minute, some tasks need more frequent updates. > > > Also, would prefer not to have to set up cron -- it's a pain to make > > > sure that the environment gets set up properly. And then the > > > configuration is kept in multiple places. > > > > > > On 9/28/07, Chris Hall wrote: > > >> cron + script/runner > > >> > > >> On 9/28/07, Joe Van Dyk wrote: > > >>> So, what's the status of this project? I'm a little confused. The > > >>> documentation at http://backgroundrb.rubyforge.org seems out of > > >>> date. > > >>> It refers to http://svn.devjavu.com/backgroundrb/tags/release-0.2.1, > > >>> which doesn't work. > > >>> > > >>> All I want is a way to easily set up tasks that should run > > >>> periodically. Some stuff should run every 10 seconds, some stuff > > >>> once > > >>> a day, etc. The tasks will need to access Rails models and save > > >>> data. > > >>> There's maybe 10 or so different periodic tasks. > > >>> > > >>> What version should I be using? trunk? 0.2.1? Do you guys need a > > >>> project hosting space? How can I help? > > >>> > > >>> Joe > > >>> _______________________________________________ > > >>> Backgroundrb-devel mailing list > > >>> Backgroundrb-devel at rubyforge.org > > >>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > >>> > > >> > > > _______________________________________________ > > > Backgroundrb-devel mailing list > > > Backgroundrb-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > ----------------------------------------------------- > > Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com > > > > > > > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > _______________________________________________ > 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 From gethemant at gmail.com Wed Oct 24 09:58:54 2007 From: gethemant at gmail.com (hemant) Date: Wed, 24 Oct 2007 19:28:54 +0530 Subject: [Backgroundrb-devel] Need advice - which version to use? In-Reply-To: <011701c81640$acf40390$6401a8c0@Precision670> References: <011701c81640$acf40390$6401a8c0@Precision670> Message-ID: On 10/24/07, Bill Walton wrote: > > > Greetings! > > I could use some advice on which version of BackgrounDrb to use in my > current situation. I've implemented the initial, single-process > multi-threaded version in a previous site, but have no experience with the > new version. Current situation is as follows. > > The application involves personal health information and so has very > stringent session management requirements. My question derives from the > need to reset the session (to require re-login) when the visitor closes > their browser. Current thought-process is to use periodically_call_remote > to set a session variable that can be checked by a worker to determine > whether or not the browser is still there. > > Anybody got any thoughts to share on the pros and cons of either version of > BackgrounDrb for this? > Although you can try the trunk version of BackgroundDrb, which works most of the time. I will be putting a new version of BackgroundDrb up on this weekend, so watchout. -- 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 From bill.walton at charter.net Wed Oct 24 10:31:17 2007 From: bill.walton at charter.net (Bill Walton) Date: Wed, 24 Oct 2007 10:31:17 -0400 Subject: [Backgroundrb-devel] Need advice - which version to use? References: <011701c81640$acf40390$6401a8c0@Precision670> Message-ID: <015501c8164a$89bdafc0$6401a8c0@Precision670> Hi hemant, hemant wrote: > On 10/24/07, Bill Walton wrote: > > > > Anybody got any thoughts to share on the pros and cons of either version of > > BackgrounDrb for this? > > > > Although you can try the trunk version of BackgroundDrb, which works > most of the time. I will be putting a new version of BackgroundDrb up > on this weekend, so watchout. > I should have mentioned another component of the decision I'm facing .... Our current deployment is ruby / mongrel cluster but we hope / plan to move to JRuby / JBoss in the near future. (That was our initial rollout but experience showed that our infrastructure team wasn't staffed / tooled to support it, so we had to roll back to our current deployment). I just had an IRC chat with Skaar on the jruby channel and he says trunk won't work with jruby. He says the old version might, and he says that your upcoming implementation might be even better suited to jruby. My needs for BackgrounDrb are pretty simple at this point: just periodically checking a session variable to see if it's been updated. I need to do my best to make sure that whatever I do on this front doesn't have a negative impact on our move to JRuby. Would definitely appreciate any thoughts you'd be willing to share on this front. Thanks, Bill From gethemant at gmail.com Wed Oct 24 10:42:27 2007 From: gethemant at gmail.com (hemant) Date: Wed, 24 Oct 2007 20:12:27 +0530 Subject: [Backgroundrb-devel] Need advice - which version to use? In-Reply-To: <015501c8164a$89bdafc0$6401a8c0@Precision670> References: <011701c81640$acf40390$6401a8c0@Precision670> <015501c8164a$89bdafc0$6401a8c0@Precision670> Message-ID: On 10/24/07, Bill Walton wrote: > Hi hemant, > > hemant wrote: > > > > On 10/24/07, Bill Walton wrote: > > > > > > Anybody got any thoughts to share on the pros and cons of either version > of > > > BackgrounDrb for this? > > > > > > > Although you can try the trunk version of BackgroundDrb, which works > > most of the time. I will be putting a new version of BackgroundDrb up > > on this weekend, so watchout. > > > > I should have mentioned another component of the decision I'm facing .... > > Our current deployment is ruby / mongrel cluster but we hope / plan to move > to JRuby / JBoss in the near future. (That was our initial rollout but > experience showed that our infrastructure team wasn't staffed / tooled to > support it, so we had to roll back to our current deployment). > > I just had an IRC chat with Skaar on the jruby channel and he says trunk > won't work with jruby. He says the old version might, and he says that your > upcoming implementation might be even better suited to jruby. My needs for > BackgrounDrb are pretty simple at this point: just periodically checking a > session variable to see if it's been updated. I need to do my best to make > sure that whatever I do on this front doesn't have a negative impact on our > move to JRuby. Would definitely appreciate any thoughts you'd be willing to > share on this front. > Do you need to trigger this check from rails? If yes ( as i think, you want this), then please evaluate trunk of backgroundrb. It should work. As for Jruby compatibility, I can't comment on that, I currently have little plans of porting it to jruby. -- 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 From bill.walton at charter.net Wed Oct 24 11:35:37 2007 From: bill.walton at charter.net (Bill Walton) Date: Wed, 24 Oct 2007 11:35:37 -0400 Subject: [Backgroundrb-devel] Need advice - which version to use? References: <011701c81640$acf40390$6401a8c0@Precision670> <015501c8164a$89bdafc0$6401a8c0@Precision670> Message-ID: <018301c81653$86b42a30$6401a8c0@Precision670> hemant wrote: > > Do you need to trigger this check from rails? If yes ( as i think, you > want this), then please evaluate trunk of backgroundrb. It should > work. I'm not an infrastructure-type guy. Don't know much at all about the issues / implications of single-process/multi-threaded vs. multi-process/single-threaded choice the two versions of BackgrounDrb put in front of me. I sure could use some advice on the pros / cons of each. Our current environment is 4 app servers (dual processor, 4GB) with each running Rails and a 60-mongrel cluster, hardware loadbalancers in front them, Apache / HAproxy in front of the mongrels. All 4 talk to a MySQL cluster running on separate hardware. Session store is ActiveRecord. Any thoughts re: pros/cons of the two architectures would really be appreciated. > > As for Jruby compatibility, I can't comment on that, I currently have > little plans of porting it to jruby. > Skaar's comment was that trunk will definitely not work on JRuby. Slave will have to be re-written. He said that the old version might work. I haven't tested it yet. In either event, if we (the company I work for) need to make mods to use either version of BackgrounDrb on JRuby in the future, I'm pretty sure we'll be able / willing to contribute it back. Looking forward to hearing your thoughts. Thanks, Bill From nathan.phelps at docvia.com Fri Oct 26 17:19:59 2007 From: nathan.phelps at docvia.com (Nathan Phelps) Date: Fri, 26 Oct 2007 17:19:59 -0400 Subject: [Backgroundrb-devel] BackgroundRB on Windows: UNIXServer required! Message-ID: I have Backgroundrb working with a Rails project on my OS X box at work, but when I attempt to run migrations or tests at home on my windows box, it fails stating: UNIXServer required! If I remove Backgroundrb from the plugins directory, things work on Windows so I know this is somehow related to Backgroundrb. Does anyone have a tip on what might be going on? Thanks, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20071026/2f94ae62/attachment-0001.html From gethemant at gmail.com Sat Oct 27 00:04:20 2007 From: gethemant at gmail.com (hemant) Date: Sat, 27 Oct 2007 09:34:20 +0530 Subject: [Backgroundrb-devel] BackgroundRB on Windows: UNIXServer required! In-Reply-To: References: Message-ID: On 10/27/07, Nathan Phelps wrote: > > > > > I have Backgroundrb working with a Rails project on my OS X box at work, but > when I attempt to run migrations or tests at home on my windows box, it > fails stating: UNIXServer required! If I remove Backgroundrb from the > plugins directory, things work on Windows so I know this is somehow related > to Backgroundrb. Does anyone have a tip on what might be going on? > Trunk version of Bdrb depends upon unix specific stuff and won't run on Windows. Read the README file. > > > Thanks, > > > > Nathan > _______________________________________________ > 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 From p.wood at lancaster.ac.uk Mon Oct 29 19:13:07 2007 From: p.wood at lancaster.ac.uk (Wood, Peter) Date: Mon, 29 Oct 2007 23:13:07 -0000 Subject: [Backgroundrb-devel] BackgrounDRb, Schedule and Clean Up Message-ID: <89C606D37C22D743B282A6B80CEE040201AC06@exchange-be3.lancs.local> Hey all, I've come accross BackgrounDRb and I have to say it's a wounderful piece of software. It has the potential to solve so many of the problems that I am facing with a current RoR project. Like many others I was having issues with the scheduling side of things, I noticed that hemant said there was a new version coming out. So I checked out the version from trunk, and have given that a go. It does appear to have solved the issue of the scheduler just stopping. Now I reread his comments and see that there is a new version in the works, which I'm sure will be great. However a question about the current trunk version, I have for pure testing purposes a worker scheduled to run every second. As I've read in the examples or the RubyDoc you have to delete the worker in order to end the Ruby process. I have noticed however that the sockets in /tmp/backgroundrb.#{pid} seem to exist until the entire backgroundrb server is stoped. Should these clear up on their own without a stop or am I doing something wrong? At current for testing I have... class NACWorker < BackgrounDRb::Worker::RailsBase def do_work(args) logger.info("Work Started") sleep 0.5 logger.info("Work Done") delete end end NACWorker.register Is delete the corrrect way to end the worker, I've had a look through RubyDoc and can't find anything more suitable? Of course I could be being an idiot and missing something. Also hemant mentioned the new version should be out at the weekend, I can't find the new version on the website, but I would imagin that it's slipped I know what that's like with my time on personal projects. Is there any chance it will be released soon? Any information would be appreciated, and thanks to current and previous maintainers! Kind regards, Peter. From andre at myavalaunch.com Wed Oct 31 14:25:17 2007 From: andre at myavalaunch.com (Andre Borrelly) Date: Wed, 31 Oct 2007 12:25:17 -0600 Subject: [Backgroundrb-devel] =?utf-8?q?Persistence_of_scheduled_jobs=3F?= Message-ID: <4ffe31fe2e96570eb6176772177accae@localhost> Hello all, I'm new to Ruby and have come across this project that seems to be the most mature scheduling project for Ruby. I've had some brief experience with Quartz for Java and was wondering if there were any plans to provide an option to save scheduled jobs into some sort of data store? If not, is that something the project would be interested in? Has someone implemented something similar using BackgroundRb? Thanks, Andre -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20071031/2bf0b86a/attachment.html From gethemant at gmail.com Wed Oct 31 18:51:13 2007 From: gethemant at gmail.com (hemant) Date: Thu, 1 Nov 2007 04:21:13 +0530 Subject: [Backgroundrb-devel] BackgrounDRb, Schedule and Clean Up In-Reply-To: <89C606D37C22D743B282A6B80CEE040201AC06@exchange-be3.lancs.local> References: <89C606D37C22D743B282A6B80CEE040201AC06@exchange-be3.lancs.local> Message-ID: On 10/30/07, Wood, Peter wrote: > > Hey all, > > I've come accross BackgrounDRb and I have to say it's a wounderful piece of software. It has the potential to solve so many of the problems that I am facing with a current RoR project. > > Like many others I was having issues with the scheduling side of things, I noticed that hemant said there was a new version coming out. So I checked out the version from trunk, and have given that a go. It does appear to have solved the issue of the scheduler just stopping. Now I reread his comments and see that there is a new version in the works, which I'm sure will be great. > > However a question about the current trunk version, I have for pure testing purposes a worker scheduled to run every second. As I've read in the examples or the RubyDoc you have to delete the worker in order to end the Ruby process. I have noticed however that the sockets in /tmp/backgroundrb.#{pid} seem to exist until the entire backgroundrb server is stoped. Should these clear up on their own without a stop or am I doing something wrong? > > At current for testing I have... > > class NACWorker < BackgrounDRb::Worker::RailsBase > def do_work(args) > logger.info("Work Started") > sleep 0.5 > logger.info("Work Done") > delete > end > end > NACWorker.register > > Is delete the corrrect way to end the worker, I've had a look through RubyDoc and can't find anything more suitable? Of course I could be being an idiot and missing something. > > Also hemant mentioned the new version should be out at the weekend, I can't find the new version on the website, but I would imagin that it's slipped I know what that's like with my time on personal projects. > Hmm, Unfortunately, I am still testing my current code and wanted to ask couple of questions. Sorry for delay. > Is there any chance it will be released soon? > > Any information would be appreciated, and thanks to current and previous maintainers! > > Kind regards, > > Peter. > _______________________________________________ > 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 From gethemant at gmail.com Wed Oct 31 18:52:08 2007 From: gethemant at gmail.com (hemant) Date: Thu, 1 Nov 2007 04:22:08 +0530 Subject: [Backgroundrb-devel] Persistence of scheduled jobs? In-Reply-To: <4ffe31fe2e96570eb6176772177accae@localhost> References: <4ffe31fe2e96570eb6176772177accae@localhost> Message-ID: On 10/31/07, Andre Borrelly wrote: > Hello all, > > I'm new to Ruby and have come across this project that seems to be the most > mature scheduling project for Ruby. I've had some brief experience with > Quartz for Java and was wondering if there were any plans to provide an > option to save scheduled jobs into some sort of data store? > > If not, is that something the project would be interested in? > > Has someone implemented something similar using BackgroundRb? > Hmm, does sound like a neat idea. I will give it a shot in the new version. -- 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 From gethemant at gmail.com Wed Oct 31 19:07:34 2007 From: gethemant at gmail.com (hemant) Date: Thu, 1 Nov 2007 04:37:34 +0530 Subject: [Backgroundrb-devel] How you want BackgrounDrb to behave Message-ID: Hi, Ok, As i promised.. I am working on new version of BackgrounDRB, which is getting close and will be out soon. I need some feedback from you guys. So, please reply back. The code has changed significantly and its no longer using DRB. But I will keep the name BackgroundRb. Ok, in new API, a worker looks like this: require "net/smtp" require "guid" class NewsletterWorker < Packet::Worker set_worker_name :newsletter_worker def worker_init puts "starting the worker" end def receive_data p_data end # this is where a request from rails will be received. so implement this method # if you want to trigger your workers from rails. def receive_internal_data p_data self.send(p_data[:method],p_data[:data]) end def send_mail data end end And you can invoke a method in worker from rails using: # invoke method send_mail in newsletter_worker WorkerProxy.send_request(:worker => :newsletter_worker, :method => :send_mail, :data => @newsletter.id) # No Kidding, guys above code works. Also, as usual you define your workers in a worker directory and they will be picked and run. Now, It should be noted that, part of stability that comes to new version is because of total lack of threads. Even timers are implemented using evented model of programming. Right now, we have two methods "add_timer" and "add_periodic_timer" available in all the workers, which can be used to schedule a job. A sample use case is: def worker_init add_periodic_timer(10) { puts "Hello World : #{Time.now}"} end Older version of BackgrounDrb was having a seperate file which was used for reading worker schedules. I am thinking of getting rid of that file and making all the workers self contained. What you guys think? Things that are not working: 1. There is no worker.delete or self.delete to stop a worker. But since, your workers are seperate processes, you can call exit on them. 2. Since older version of BackgrounDrb used threads. The famous progress bar example, that came with initial version of BackgrounDrb worked. But new version has a event loop around all the workers and thats how it runs timers and can trigger callbacks. So progress bar example, will have to reworked using callback mechanism, rather than threads. PS: trunk doesn't yet reflect the changes i said. I will be checking in code soon. stay tuned. -- 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 From jim.scott at yahoo.com Wed Oct 31 19:23:09 2007 From: jim.scott at yahoo.com (Jim Scott) Date: Wed, 31 Oct 2007 17:23:09 -0600 Subject: [Backgroundrb-devel] How you want BackgrounDrb to behave In-Reply-To: References: Message-ID: <00e101c81c15$00e5a4c0$9601a8c0@LIGHTFOOT> Thank you for your hard work. Getting rid of threads will help stability immensely. Re: the file for scheduled jobs. Remove away. I would much rather have the scheduling definition contained in the object rather than yet another configuration file. Jim Scott -----Original Message----- From: backgroundrb-devel-bounces at rubyforge.org [mailto:backgroundrb-devel-bounces at rubyforge.org] On Behalf Of hemant Sent: Wednesday, October 31, 2007 5:08 PM To: backgroundrb-devel at rubyforge.org Subject: [Backgroundrb-devel] How you want BackgrounDrb to behave Hi, Ok, As i promised.. I am working on new version of BackgrounDRB, which is getting close and will be out soon. I need some feedback from you guys. So, please reply back. The code has changed significantly and its no longer using DRB. But I will keep the name BackgroundRb. Ok, in new API, a worker looks like this: require "net/smtp" require "guid" class NewsletterWorker < Packet::Worker set_worker_name :newsletter_worker def worker_init puts "starting the worker" end def receive_data p_data end # this is where a request from rails will be received. so implement this method # if you want to trigger your workers from rails. def receive_internal_data p_data self.send(p_data[:method],p_data[:data]) end def send_mail data end end And you can invoke a method in worker from rails using: # invoke method send_mail in newsletter_worker WorkerProxy.send_request(:worker => :newsletter_worker, :method => :send_mail, :data => @newsletter.id) # No Kidding, guys above code works. Also, as usual you define your workers in a worker directory and they will be picked and run. Now, It should be noted that, part of stability that comes to new version is because of total lack of threads. Even timers are implemented using evented model of programming. Right now, we have two methods "add_timer" and "add_periodic_timer" available in all the workers, which can be used to schedule a job. A sample use case is: def worker_init add_periodic_timer(10) { puts "Hello World : #{Time.now}"} end Older version of BackgrounDrb was having a seperate file which was used for reading worker schedules. I am thinking of getting rid of that file and making all the workers self contained. What you guys think? Things that are not working: 1. There is no worker.delete or self.delete to stop a worker. But since, your workers are seperate processes, you can call exit on them. 2. Since older version of BackgrounDrb used threads. The famous progress bar example, that came with initial version of BackgrounDrb worked. But new version has a event loop around all the workers and thats how it runs timers and can trigger callbacks. So progress bar example, will have to reworked using callback mechanism, rather than threads. PS: trunk doesn't yet reflect the changes i said. I will be checking in code soon. stay tuned. -- 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 _______________________________________________ Backgroundrb-devel mailing list Backgroundrb-devel at rubyforge.org http://rubyforge.org/mailman/listinfo/backgroundrb-devel No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.16/1102 - Release Date: 10/31/2007 4:38 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.16/1102 - Release Date: 10/31/2007 4:38 PM From ezmobius at gmail.com Wed Oct 31 19:36:25 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Wed, 31 Oct 2007 16:36:25 -0700 Subject: [Backgroundrb-devel] How you want BackgrounDrb to behave In-Reply-To: References: Message-ID: <8AEC11FA-4212-4655-AF7F-FA1AB71AB001@brainspl.at> Sweet deal hemant, this will be a big improvement. -Ezra On Oct 31, 2007, at 4:07 PM, hemant wrote: > Hi, > > Ok, As i promised.. I am working on new version of BackgrounDRB, which > is getting close and will be out soon. I need some feedback from you > guys. So, please reply back. > > The code has changed significantly and its no longer using DRB. But I > will keep the name BackgroundRb. Ok, in new API, a worker looks like > this: > > require "net/smtp" > require "guid" > > class NewsletterWorker < Packet::Worker > set_worker_name :newsletter_worker > def worker_init > puts "starting the worker" > end > > def receive_data p_data > end > > # this is where a request from rails will be received. so implement > this method > # if you want to trigger your workers from rails. > def receive_internal_data p_data > self.send(p_data[:method],p_data[:data]) > end > > def send_mail data > end > end > > And you can invoke a method in worker from rails using: > # invoke method send_mail in newsletter_worker > WorkerProxy.send_request(:worker => :newsletter_worker, :method => > :send_mail, :data => @newsletter.id) > # No Kidding, guys above code works. > > Also, as usual you define your workers in a worker directory and they > will be picked and run. > > Now, It should be noted that, part of stability that comes to new > version is because of total lack of threads. Even timers are > implemented using evented model of programming. Right now, we have two > methods "add_timer" and "add_periodic_timer" available in all the > workers, which can be used to schedule a job. > > A sample use case is: > > def worker_init > add_periodic_timer(10) { puts "Hello World : #{Time.now}"} > end > > Older version of BackgrounDrb was having a seperate file which was > used for reading worker schedules. I am thinking of getting rid of > that file and making all the workers self contained. > What you guys think? > > > Things that are not working: > 1. There is no worker.delete or self.delete to stop a worker. But > since, your workers are seperate processes, you can call exit on them. > 2. Since older version of BackgrounDrb used threads. The famous > progress bar example, that came with initial version of BackgrounDrb > worked. But new version has a event loop around all the workers and > thats how it runs timers and can trigger callbacks. So progress bar > example, will have to reworked using callback mechanism, rather than > threads. > > > PS: trunk doesn't yet reflect the changes i said. I will be checking > in code soon. stay tuned. > > > -- > > 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 > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > From benr at x-cr.com Wed Oct 31 20:39:24 2007 From: benr at x-cr.com (Ben Reubenstein) Date: Wed, 31 Oct 2007 18:39:24 -0600 Subject: [Backgroundrb-devel] How you want BackgrounDrb to behave In-Reply-To: <8AEC11FA-4212-4655-AF7F-FA1AB71AB001@brainspl.at> References: <8AEC11FA-4212-4655-AF7F-FA1AB71AB001@brainspl.at> Message-ID: <44c79a160710311739h23ca68e5ie027ae5b59f9d42c@mail.gmail.com> Holler if you need testers. I have several apps that are using BackgroundRb, one which is in development stages. ~ Ben On 10/31/07, Ezra Zygmuntowicz wrote: > Sweet deal hemant, this will be a big improvement. > > -Ezra > > On Oct 31, 2007, at 4:07 PM, hemant wrote: > > > Hi, > > > > Ok, As i promised.. I am working on new version of BackgrounDRB, which > > is getting close and will be out soon. I need some feedback from you > > guys. So, please reply back. > > > > The code has changed significantly and its no longer using DRB. But I > > will keep the name BackgroundRb. Ok, in new API, a worker looks like > > this: > > > > require "net/smtp" > > require "guid" > > > > class NewsletterWorker < Packet::Worker > > set_worker_name :newsletter_worker > > def worker_init > > puts "starting the worker" > > end > > > > def receive_data p_data > > end > > > > # this is where a request from rails will be received. so implement > > this method > > # if you want to trigger your workers from rails. > > def receive_internal_data p_data > > self.send(p_data[:method],p_data[:data]) > > end > > > > def send_mail data > > end > > end > > > > And you can invoke a method in worker from rails using: > > # invoke method send_mail in newsletter_worker > > WorkerProxy.send_request(:worker => :newsletter_worker, :method => > > :send_mail, :data => @newsletter.id) > > # No Kidding, guys above code works. > > > > Also, as usual you define your workers in a worker directory and they > > will be picked and run. > > > > Now, It should be noted that, part of stability that comes to new > > version is because of total lack of threads. Even timers are > > implemented using evented model of programming. Right now, we have two > > methods "add_timer" and "add_periodic_timer" available in all the > > workers, which can be used to schedule a job. > > > > A sample use case is: > > > > def worker_init > > add_periodic_timer(10) { puts "Hello World : #{Time.now}"} > > end > > > > Older version of BackgrounDrb was having a seperate file which was > > used for reading worker schedules. I am thinking of getting rid of > > that file and making all the workers self contained. > > What you guys think? > > > > > > Things that are not working: > > 1. There is no worker.delete or self.delete to stop a worker. But > > since, your workers are seperate processes, you can call exit on them. > > 2. Since older version of BackgrounDrb used threads. The famous > > progress bar example, that came with initial version of BackgrounDrb > > worked. But new version has a event loop around all the workers and > > thats how it runs timers and can trigger callbacks. So progress bar > > example, will have to reworked using callback mechanism, rather than > > threads. > > > > > > PS: trunk doesn't yet reflect the changes i said. I will be checking > > in code soon. stay tuned. > > > > > > -- > > > > 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 > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Ben Reubenstein 303-947-0446 http://www.x-cr.com From gethemant at gmail.com Wed Oct 31 20:45:34 2007 From: gethemant at gmail.com (hemant) Date: Thu, 1 Nov 2007 06:15:34 +0530 Subject: [Backgroundrb-devel] How you want BackgrounDrb to behave In-Reply-To: <44c79a160710311739h23ca68e5ie027ae5b59f9d42c@mail.gmail.com> References: <8AEC11FA-4212-4655-AF7F-FA1AB71AB001@brainspl.at> <44c79a160710311739h23ca68e5ie027ae5b59f9d42c@mail.gmail.com> Message-ID: On 11/1/07, Ben Reubenstein wrote: > Holler if you need testers. I have several apps that are using > BackgroundRb, one which is in development stages. > Yup, You are more than welcome. Wait for the pre-release. > ~ Ben > > On 10/31/07, Ezra Zygmuntowicz wrote: > > Sweet deal hemant, this will be a big improvement. > > > > -Ezra Thanks Ezra. Jim: Ok then, we will be taking out schedules.yml file altogether. I hope, it doesn't piss off people. -- 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