From jeffrey.schoolcraft at gmail.com Wed Oct 1 13:34:00 2008 From: jeffrey.schoolcraft at gmail.com (Jeff Schoolcraft) Date: Wed, 1 Oct 2008 13:34:00 -0400 Subject: [Backgroundrb-devel] monitoring backgroundrb with god Message-ID: <55e1a7fa0810011034j15cd58eepfebe97b83644c240@mail.gmail.com> I'm trying to get robotpoke's god script to work in my environment. His original is here: http://robotpoke.blogspot.com/2008/08/monitoring-backgroundrb-workers-with.html I've only modified the test to see if a worker is running, line 27 in this gist: http://gist.github.com/14089 If you look at the console output it doesn't look like it's ever getting into that method. Does anyone have any idea why? Jeff -- Jeff Schoolcraft http://thequeue.net/blog/ Microsoft MVP -------------- next part -------------- An HTML attachment was scrubbed... URL: From gethemant at gmail.com Thu Oct 2 05:38:25 2008 From: gethemant at gmail.com (hemant) Date: Thu, 2 Oct 2008 15:08:25 +0530 Subject: [Backgroundrb-devel] Call for help Message-ID: Hi folks, I am planning to put forth 1.1 release, but there are two issues, that I would like to get solved before the release and I need your help. 1. Mac OS X issue: About newly started worker being unusable for fraction of seconds. Ideally, it should work as Linux and other OSes, but it doesn't because of problem with read_nonblock (which should work across unixes at least well enough). The fix will only come through trial and error and we will have to workaround this problem. Not having a Mac machine is a bit of hurdle for me, so if possible, try changing read from socket code in "packet_nbio.rb" and see, what fixes the problem (and what causes the problem). Or else, if possible for any of you, I shall be thankful for Mac OSX shell account for a week or so. 2. Need to verify and fix, issue with bdrb when packet is frozen in vendor directory (it should be really minor issue). Changes that will go in this release: 1. Better start/stop daemon managment (as previously discussed on list) 2. logger.warn and friends for logging. 3. fixes and patch for scheduled_at. 4. When using "reload_on_schedule" option, previous instance of worker should be killed, before starting new one. 5. job table migration patch by Seth. 6. Some documentation fixes. 7. Fixes for some closed bugs on backgroundrb trac page. 8. FAQ page for known issues/workarounds. 9. More test coverage! Lastly, I need working monit/god/capistrano configuration that folks are using for managing backgroundrb server. (Please submit a patch or just use gist.github.com or pastie). If I have missed any of important bugs/issues, please reply to this thread. -- 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 alias at pet-theory.com Thu Oct 2 14:17:53 2008 From: alias at pet-theory.com (Matt Garland) Date: Thu, 2 Oct 2008 11:17:53 -0700 Subject: [Backgroundrb-devel] enqueued tasks running but not needed Message-ID: <647436F8-043C-4AB0-9A23-E38E5E2EFC76@pet-theory.com> I have two workers--jabber_worker, election_worker--and both are working great. BUT I can see in my rails console that the queue table is being constantly polled for jabber_worker: BdrbJobQueue Load (0.002401) SELECT * FROM `bdrb_job_queues` WHERE (`bdrb_job_queues`.`taken` = 0 AND `bdrb_job_queues`.`worker_name` = 'jabber_worker') LIMIT 1 FOR UPDATE EVEN though my configuration file rules out enqueued tasks: :backgroundrb: :port: 22222 :ip: 0.0.0.0 :environment: development :log: foreground :debug_log: true :persistent_disabled: true I'm not sure why this is happening. It's true that I created jabber_worker BEFORE changing the configuration. But even when I rerun the rake set up, this persists. So why is the config overrun? And why only for :jabber_worker? I should say I am on OS X. I should also say I don't understand exactly what the persisted queue is. I imagine it is useful for long-running jobs when some kind of logic is being applied to what goes next, and that logic can change. That's not my case. jabber_worker just contacts a jabber server, pushing data out, adding and deleting users. election_worker maintains separate threads for a group of chat rooms, and kills or restarts them when the rails app tells it to, and it tells the rails app when an election period in a chat room is over and votes need to be counted. Here's jabber worker: class JabberWorker < BackgrounDRb::MetaWorker require 'xmpp4r/client' require 'xmpp4r/muc' set_worker_name :jabber_worker def create(args = nil) jid = Jabber::JID.new("#{JABBER_ADMIN}@#{JABBER_ADDRESS}/rails") @client = Jabber::Client.new(jid) @client.connect @client.auth(JABBER_PWD) @client.send(Jabber::Presence.new) @conferenceClient={} create_chats end def create_chats Chat.all.each do |chat| muc = Jabber::MUC::SimpleMUCClient.new(@client) @conferenceClient[chat.name]=muc address = "#{chat.name}@#{JABBER_CONFERENCES}.#{JABBER_ADDRESS}/ rails" muc.join(Jabber::JID.new(address)) end end def add_jabber_user(user) jid = Jabber::JID.new("#{user.login}@#{JABBER_ADDRESS}") client = Jabber::Client.new(jid) client.connect client.register(user.login) client.disconnect end def delete_jabber_user(user) jid = Jabber::JID.new("#{user.login}@#{JABBER_ADDRESS}") client = Jabber::Client.new(jid) client.connect client.auth(user.login) client.remove_registration client.disconnect end def push_individual_resource(args) jid = Jabber::JID.new("#{args[:login]}@#{JABBER_ADDRESS}") message = Jabber::Message::new(jid, args[:message]).set_type(:normal) @client.send(message) end def push_conference_resource(args) jid = Jabber ::JID.new("#{args[:chat_name]}@#{JABBER_CONFERENCES}.#{JABBER_ADDRESS}") message = Jabber::Message::new(jid, args[:message]).set_type(:groupchat) @conferenceClient[args[:chat_name]].send(message) end end And here is election_worker for comparison: class ElectionWorker< BackgrounDRb::MetaWorker set_worker_name :election_worker ELECTION_INTERVAL=10 def create(args = nil) p "election worker created" @timers={} end def stop_elections(chat_id) if @timers.key? chat_id @timers[chat_id].kill end p "elections stopped for #{chat_id}" end def start_elections(chat_id) p "elections started for #{chat_id}" @timers[chat_id]=fresh_election_timer(chat_id) p "elections started for #{chat_id} AFTER" end def restart_election_cycle(chat_id) stop_elections(chat_id) start_elections(chat_id) end def fresh_election_timer(chat_id) p "fresh timer #{chat_id}" timer=Thread.new do loop do sleep ELECTION_INTERVAL Chat.find(chat_id).do_election end end timer end end From alias at pet-theory.com Thu Oct 2 15:03:19 2008 From: alias at pet-theory.com (Matt Garland) Date: Thu, 2 Oct 2008 12:03:19 -0700 Subject: [Backgroundrb-devel] enqueued tasks running but not needed In-Reply-To: <647436F8-043C-4AB0-9A23-E38E5E2EFC76@pet-theory.com> References: <647436F8-043C-4AB0-9A23-E38E5E2EFC76@pet-theory.com> Message-ID: Correction--after I ran the rake setup again, BOTH workers cause queries. BdrbJobQueue Load (0.003223) SELECT * FROM `bdrb_job_queues` WHERE (`bdrb_job_queues`.`taken` = 0 AND `bdrb_job_queues`.`worker_name` = 'election_worker') LIMIT 1 FOR UPDATE On Oct 2, 2008, at 11:08 AM, Matt Garland wrote: > I have two workers--jabber_worker, election_worker--and both are > working great. > > BUT I can see in my rails console that the queue table is being > constantly polled for jabber_worker: > > BdrbJobQueue Load (0.002401) SELECT * FROM `bdrb_job_queues` > WHERE (`bdrb_job_queues`.`taken` = 0 AND > `bdrb_job_queues`.`worker_name` = 'jabber_worker') LIMIT 1 FOR UPDATE > > EVEN though my configuration file rules out enqueued tasks: > > :backgroundrb: > :port: 22222 > :ip: 0.0.0.0 > :environment: development > :log: foreground > :debug_log: true > :persistent_disabled: true > > I'm not sure why this is happening. It's true that I created > jabber_worker BEFORE changing the configuration. But even when I > rerun the rake set up, this persists. > > So why is the config overrun? And why only for :jabber_worker? > > I should say I am on OS X. > > I should also say I don't understand exactly what the persisted > queue is. I imagine it is useful for long-running jobs when some > kind of logic is being applied to what goes next, and that logic can > change. > > That's not my case. jabber_worker just contacts a jabber server, > pushing data out, adding and deleting users. election_worker > maintains separate threads for a group of chat rooms, and kills or > restarts them when the rails app tells it to, and it tells the rails > app when an election period in a chat room is over and votes need to > be counted. > > Here's jabber worker: > > class JabberWorker < BackgrounDRb::MetaWorker > > require 'xmpp4r/client' > require 'xmpp4r/muc' > > set_worker_name :jabber_worker > > def create(args = nil) > jid = Jabber::JID.new("#{JABBER_ADMIN}@#{JABBER_ADDRESS}/rails") > @client = Jabber::Client.new(jid) > @client.connect > @client.auth(JABBER_PWD) > @client.send(Jabber::Presence.new) > @conferenceClient={} > create_chats > end > > def create_chats > Chat.all.each do |chat| > muc = Jabber::MUC::SimpleMUCClient.new(@client) > @conferenceClient[chat.name]=muc > address = "#{chat.name}@#{JABBER_CONFERENCES}.#{JABBER_ADDRESS}/ > rails" > muc.join(Jabber::JID.new(address)) > end > end > > def add_jabber_user(user) > jid = Jabber::JID.new("#{user.login}@#{JABBER_ADDRESS}") > client = Jabber::Client.new(jid) > client.connect > client.register(user.login) > client.disconnect > end > > def delete_jabber_user(user) > jid = Jabber::JID.new("#{user.login}@#{JABBER_ADDRESS}") > client = Jabber::Client.new(jid) > client.connect > client.auth(user.login) > client.remove_registration > client.disconnect > end > > def push_individual_resource(args) > jid = Jabber::JID.new("#{args[:login]}@#{JABBER_ADDRESS}") > message = Jabber::Message::new(jid, > args[:message]).set_type(:normal) > @client.send(message) > end > > def push_conference_resource(args) > jid = > Jabber > ::JID > .new("#{args[:chat_name]}@#{JABBER_CONFERENCES}.#{JABBER_ADDRESS}") > message = Jabber::Message::new(jid, > args[:message]).set_type(:groupchat) > @conferenceClient[args[:chat_name]].send(message) > end > > > end > > And here is election_worker for comparison: > > class ElectionWorker< BackgrounDRb::MetaWorker > > set_worker_name :election_worker > > ELECTION_INTERVAL=10 > > def create(args = nil) > p "election worker created" > @timers={} > end > > def stop_elections(chat_id) > if @timers.key? chat_id > @timers[chat_id].kill > end > p "elections stopped for #{chat_id}" > end > > def start_elections(chat_id) > p "elections started for #{chat_id}" > @timers[chat_id]=fresh_election_timer(chat_id) > p "elections started for #{chat_id} AFTER" > end > > def restart_election_cycle(chat_id) > stop_elections(chat_id) > start_elections(chat_id) > end > > def fresh_election_timer(chat_id) > p "fresh timer #{chat_id}" > timer=Thread.new do > loop do > sleep ELECTION_INTERVAL > Chat.find(chat_id).do_election > end > end > timer > end > > end > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From gethemant at gmail.com Thu Oct 2 23:55:08 2008 From: gethemant at gmail.com (hemant kumar) Date: Fri, 03 Oct 2008 09:25:08 +0530 Subject: [Backgroundrb-devel] enqueued tasks running but not needed In-Reply-To: References: <647436F8-043C-4AB0-9A23-E38E5E2EFC76@pet-theory.com> Message-ID: <1223006108.18037.6.camel@shire> This sounds like a bug. Are you running git version? On Thu, 2008-10-02 at 12:03 -0700, Matt Garland wrote: > Correction--after I ran the rake setup again, BOTH workers cause > queries. > > BdrbJobQueue Load (0.003223) SELECT * FROM `bdrb_job_queues` > WHERE (`bdrb_job_queues`.`taken` = 0 AND > `bdrb_job_queues`.`worker_name` = 'election_worker') LIMIT 1 FOR UPDATE > > > On Oct 2, 2008, at 11:08 AM, Matt Garland wrote: > > > I have two workers--jabber_worker, election_worker--and both are > > working great. > > > > BUT I can see in my rails console that the queue table is being > > constantly polled for jabber_worker: > > > > BdrbJobQueue Load (0.002401) SELECT * FROM `bdrb_job_queues` > > WHERE (`bdrb_job_queues`.`taken` = 0 AND > > `bdrb_job_queues`.`worker_name` = 'jabber_worker') LIMIT 1 FOR UPDATE > > > > EVEN though my configuration file rules out enqueued tasks: > > > > :backgroundrb: > > :port: 22222 > > :ip: 0.0.0.0 > > :environment: development > > :log: foreground > > :debug_log: true > > :persistent_disabled: true > > > > I'm not sure why this is happening. It's true that I created > > jabber_worker BEFORE changing the configuration. But even when I > > rerun the rake set up, this persists. > > > > So why is the config overrun? And why only for :jabber_worker? > > > > I should say I am on OS X. > > > > I should also say I don't understand exactly what the persisted > > queue is. I imagine it is useful for long-running jobs when some > > kind of logic is being applied to what goes next, and that logic can > > change. > > > > That's not my case. jabber_worker just contacts a jabber server, > > pushing data out, adding and deleting users. election_worker > > maintains separate threads for a group of chat rooms, and kills or > > restarts them when the rails app tells it to, and it tells the rails > > app when an election period in a chat room is over and votes need to > > be counted. > > > > Here's jabber worker: > > > > class JabberWorker < BackgrounDRb::MetaWorker > > > > require 'xmpp4r/client' > > require 'xmpp4r/muc' > > > > set_worker_name :jabber_worker > > > > def create(args = nil) > > jid = Jabber::JID.new("#{JABBER_ADMIN}@#{JABBER_ADDRESS}/rails") > > @client = Jabber::Client.new(jid) > > @client.connect > > @client.auth(JABBER_PWD) > > @client.send(Jabber::Presence.new) > > @conferenceClient={} > > create_chats > > end > > > > def create_chats > > Chat.all.each do |chat| > > muc = Jabber::MUC::SimpleMUCClient.new(@client) > > @conferenceClient[chat.name]=muc > > address = "#{chat.name}@#{JABBER_CONFERENCES}.#{JABBER_ADDRESS}/ > > rails" > > muc.join(Jabber::JID.new(address)) > > end > > end > > > > def add_jabber_user(user) > > jid = Jabber::JID.new("#{user.login}@#{JABBER_ADDRESS}") > > client = Jabber::Client.new(jid) > > client.connect > > client.register(user.login) > > client.disconnect > > end > > > > def delete_jabber_user(user) > > jid = Jabber::JID.new("#{user.login}@#{JABBER_ADDRESS}") > > client = Jabber::Client.new(jid) > > client.connect > > client.auth(user.login) > > client.remove_registration > > client.disconnect > > end > > > > def push_individual_resource(args) > > jid = Jabber::JID.new("#{args[:login]}@#{JABBER_ADDRESS}") > > message = Jabber::Message::new(jid, > > args[:message]).set_type(:normal) > > @client.send(message) > > end > > > > def push_conference_resource(args) > > jid = > > Jabber > > ::JID > > .new("#{args[:chat_name]}@#{JABBER_CONFERENCES}.#{JABBER_ADDRESS}") > > message = Jabber::Message::new(jid, > > args[:message]).set_type(:groupchat) > > @conferenceClient[args[:chat_name]].send(message) > > end > > > > > > end > > > > And here is election_worker for comparison: > > > > class ElectionWorker< BackgrounDRb::MetaWorker > > > > set_worker_name :election_worker > > > > ELECTION_INTERVAL=10 > > > > def create(args = nil) > > p "election worker created" > > @timers={} > > end > > > > def stop_elections(chat_id) > > if @timers.key? chat_id > > @timers[chat_id].kill > > end > > p "elections stopped for #{chat_id}" > > end > > > > def start_elections(chat_id) > > p "elections started for #{chat_id}" > > @timers[chat_id]=fresh_election_timer(chat_id) > > p "elections started for #{chat_id} AFTER" > > end > > > > def restart_election_cycle(chat_id) > > stop_elections(chat_id) > > start_elections(chat_id) > > end > > > > def fresh_election_timer(chat_id) > > p "fresh timer #{chat_id}" > > timer=Thread.new do > > loop do > > sleep ELECTION_INTERVAL > > Chat.find(chat_id).do_election > > end > > end > > timer > > end > > > > end > > _______________________________________________ > > 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 From alias at pet-theory.com Fri Oct 3 00:36:48 2008 From: alias at pet-theory.com (Matt Garland) Date: Thu, 2 Oct 2008 21:36:48 -0700 Subject: [Backgroundrb-devel] enqueued tasks running but not needed In-Reply-To: <1223006108.18037.6.camel@shire> References: <647436F8-043C-4AB0-9A23-E38E5E2EFC76@pet-theory.com> <1223006108.18037.6.camel@shire> Message-ID: <6B8A5AF3-9DE4-4625-AC83-5F03595167CA@pet-theory.com> Thanks Hemant, that did the trick! I had been running the latest svn. I have a MacBook that my wife mostly surfs the web with. It's running Leopard OS and we have cable DSL in the American Northwest. I'm not sure how to set up shell access, but if you think you can use it, give me a holler. matt at pet-theory dot com. On Oct 2, 2008, at 8:08 PM, hemant kumar wrote: > This sounds like a bug. Are you running git version? > > On Thu, 2008-10-02 at 12:03 -0700, Matt Garland wrote: >> Correction--after I ran the rake setup again, BOTH workers cause >> queries. >> >> BdrbJobQueue Load (0.003223) SELECT * FROM `bdrb_job_queues` >> WHERE (`bdrb_job_queues`.`taken` = 0 AND >> `bdrb_job_queues`.`worker_name` = 'election_worker') LIMIT 1 FOR >> UPDATE >> >> >> On Oct 2, 2008, at 11:08 AM, Matt Garland wrote: >> >>> I have two workers--jabber_worker, election_worker--and both are >>> working great. >>> >>> BUT I can see in my rails console that the queue table is being >>> constantly polled for jabber_worker: >>> >>> BdrbJobQueue Load (0.002401) SELECT * FROM `bdrb_job_queues` >>> WHERE (`bdrb_job_queues`.`taken` = 0 AND >>> `bdrb_job_queues`.`worker_name` = 'jabber_worker') LIMIT 1 FOR >>> UPDATE >>> >>> EVEN though my configuration file rules out enqueued tasks: >>> >>> :backgroundrb: >>> :port: 22222 >>> :ip: 0.0.0.0 >>> :environment: development >>> :log: foreground >>> :debug_log: true >>> :persistent_disabled: true >>> >>> I'm not sure why this is happening. It's true that I created >>> jabber_worker BEFORE changing the configuration. But even when I >>> rerun the rake set up, this persists. >>> >>> So why is the config overrun? And why only for :jabber_worker? >>> >>> I should say I am on OS X. >>> >>> I should also say I don't understand exactly what the persisted >>> queue is. I imagine it is useful for long-running jobs when some >>> kind of logic is being applied to what goes next, and that logic can >>> change. >>> >>> That's not my case. jabber_worker just contacts a jabber server, >>> pushing data out, adding and deleting users. election_worker >>> maintains separate threads for a group of chat rooms, and kills or >>> restarts them when the rails app tells it to, and it tells the rails >>> app when an election period in a chat room is over and votes need to >>> be counted. >>> >>> Here's jabber worker: >>> >>> class JabberWorker < BackgrounDRb::MetaWorker >>> >>> require 'xmpp4r/client' >>> require 'xmpp4r/muc' >>> >>> set_worker_name :jabber_worker >>> >>> def create(args = nil) >>> jid = Jabber::JID.new("#{JABBER_ADMIN}@#{JABBER_ADDRESS}/rails") >>> @client = Jabber::Client.new(jid) >>> @client.connect >>> @client.auth(JABBER_PWD) >>> @client.send(Jabber::Presence.new) >>> @conferenceClient={} >>> create_chats >>> end >>> >>> def create_chats >>> Chat.all.each do |chat| >>> muc = Jabber::MUC::SimpleMUCClient.new(@client) >>> @conferenceClient[chat.name]=muc >>> address = "#{chat.name}@#{JABBER_CONFERENCES}.#{JABBER_ADDRESS}/ >>> rails" >>> muc.join(Jabber::JID.new(address)) >>> end >>> end >>> >>> def add_jabber_user(user) >>> jid = Jabber::JID.new("#{user.login}@#{JABBER_ADDRESS}") >>> client = Jabber::Client.new(jid) >>> client.connect >>> client.register(user.login) >>> client.disconnect >>> end >>> >>> def delete_jabber_user(user) >>> jid = Jabber::JID.new("#{user.login}@#{JABBER_ADDRESS}") >>> client = Jabber::Client.new(jid) >>> client.connect >>> client.auth(user.login) >>> client.remove_registration >>> client.disconnect >>> end >>> >>> def push_individual_resource(args) >>> jid = Jabber::JID.new("#{args[:login]}@#{JABBER_ADDRESS}") >>> message = Jabber::Message::new(jid, >>> args[:message]).set_type(:normal) >>> @client.send(message) >>> end >>> >>> def push_conference_resource(args) >>> jid = >>> Jabber >>> ::JID >>> .new("#{args[:chat_name]}@#{JABBER_CONFERENCES}.#{JABBER_ADDRESS}") >>> message = Jabber::Message::new(jid, >>> args[:message]).set_type(:groupchat) >>> @conferenceClient[args[:chat_name]].send(message) >>> end >>> >>> >>> end >>> >>> And here is election_worker for comparison: >>> >>> class ElectionWorker< BackgrounDRb::MetaWorker >>> >>> set_worker_name :election_worker >>> >>> ELECTION_INTERVAL=10 >>> >>> def create(args = nil) >>> p "election worker created" >>> @timers={} >>> end >>> >>> def stop_elections(chat_id) >>> if @timers.key? chat_id >>> @timers[chat_id].kill >>> end >>> p "elections stopped for #{chat_id}" >>> end >>> >>> def start_elections(chat_id) >>> p "elections started for #{chat_id}" >>> @timers[chat_id]=fresh_election_timer(chat_id) >>> p "elections started for #{chat_id} AFTER" >>> end >>> >>> def restart_election_cycle(chat_id) >>> stop_elections(chat_id) >>> start_elections(chat_id) >>> end >>> >>> def fresh_election_timer(chat_id) >>> p "fresh timer #{chat_id}" >>> timer=Thread.new do >>> loop do >>> sleep ELECTION_INTERVAL >>> Chat.find(chat_id).do_election >>> end >>> end >>> timer >>> end >>> >>> end >>> _______________________________________________ >>> 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 > From gethemant at gmail.com Fri Oct 3 05:00:48 2008 From: gethemant at gmail.com (hemant) Date: Fri, 3 Oct 2008 14:30:48 +0530 Subject: [Backgroundrb-devel] enqueued tasks running but not needed In-Reply-To: <6B8A5AF3-9DE4-4625-AC83-5F03595167CA@pet-theory.com> References: <647436F8-043C-4AB0-9A23-E38E5E2EFC76@pet-theory.com> <1223006108.18037.6.camel@shire> <6B8A5AF3-9DE4-4625-AC83-5F03595167CA@pet-theory.com> Message-ID: On Fri, Oct 3, 2008 at 10:06 AM, Matt Garland wrote: > Thanks Hemant, that did the trick! I had been running the latest svn. > > I have a MacBook that my wife mostly surfs the web with. It's running > Leopard OS and we have cable DSL in the American Northwest. I'm not sure > how to set up shell access, but if you think you can use it, give me a > holler. matt at pet-theory dot com. Cool, but Kieran already did that for me, so I am testing stuff on Mac OSX now, but thanks anyways. From gethemant at gmail.com Sat Oct 4 16:09:12 2008 From: gethemant at gmail.com (hemant) Date: Sun, 5 Oct 2008 01:39:12 +0530 Subject: [Backgroundrb-devel] Call for help In-Reply-To: References: Message-ID: On Thu, Oct 2, 2008 at 3:08 PM, hemant wrote: > Hi folks, > > I am planning to put forth 1.1 release, but there are two issues, that > I would like to get solved before the release and I need your help. > > 1. Mac OS X issue: About newly started worker being unusable for > fraction of seconds. Ideally, it should work as Linux and other OSes, > but it doesn't because of problem with read_nonblock (which should > work across unixes at least well enough). The fix will only come > through trial and error and we will have to workaround this problem. > Not having a Mac machine is a bit of hurdle for me, so if possible, > try changing read from socket code in "packet_nbio.rb" and see, what > fixes the problem (and what causes the problem). Or else, if possible > for any of you, I shall be thankful for Mac OSX shell account for a > week or so. > > 2. Need to verify and fix, issue with bdrb when packet is frozen in > vendor directory (it should be really minor issue). > > Changes that will go in this release: > > 1. Better start/stop daemon managment (as previously discussed on list) > 2. logger.warn and friends for logging. > 3. fixes and patch for scheduled_at. > 4. When using "reload_on_schedule" option, previous instance of worker > should be killed, before starting new one. > 5. job table migration patch by Seth. > 6. Some documentation fixes. > 7. Fixes for some closed bugs on backgroundrb trac page. > 8. FAQ page for known issues/workarounds. > 9. More test coverage! > > Lastly, I need working monit/god/capistrano configuration that folks > are using for managing backgroundrb server. (Please submit a patch or > just use gist.github.com or pastie). > > If I have missed any of important bugs/issues, please reply to this thread. Folks, I have pushed following changes upstream: 1. start/stop is improved now (Woody's patch has been merged!) 2. Mac OSX fixes. (You no longer will have to put a sleep() after starting a new worker. Upgrade to packet 0.1.14 for this) 2. schedule_at fixes 3. logger.warn 4. Other fixes 5. Improved documentation I couldn't get Seth's changes for separate migration scripts,otherwise we are pretty much close to 1.1 release. Give it a spin and let me know if it breaks or anything. (Don't forget to remove script/backgroundrb and script/load_worker_env.rb, before re-running rake backgroundrb:setup) From curtis.hatter at insightbb.com Tue Oct 7 03:33:52 2008 From: curtis.hatter at insightbb.com (Mitchell Curtis Hatter) Date: Tue, 7 Oct 2008 03:33:52 -0400 Subject: [Backgroundrb-devel] questions about persistent jobs Message-ID: <8E8A7398-23AF-4207-ADF2-05BBFEEE169F@insightbb.com> I've been having problems with losing async'ed tasks, so I've moved to trying to use enqueued tasks. I'm trying to offload user queries to the background, using a thread pool size of 40 and two workers (on different machines). It seems that if I exceed the thread pool size those queries get lost, or for some other reason I can't determine yet I'm losing my tasks when there are lots of them at once. For that reason I've moved to trying enqued tasks. This method seems to be fine for not losing jobs but I can't seem to run more then 2 at a time? (one for each worker). Is there a way to up the number of enqueued tasks that will be ran at a time? This way I could make use of my thread pool, and the enqueueing tasks. The behavior I expected from this method is that it checks every second (like I have configured) for enqueued tasks. Then running as many enqueued tasks as the thread pool limit for that worker. Is there a way to get this behavior from the system? Right now it seems to pull out one at a time and run them till they finish and then pull out the next. If my expected behavior isn't how it's supposed to work, would there be a way to do that? I'm running version 1.0.4 with packet 0.1.14 My drb config: --- :backgroundrb: :ip: 0.0.0.0 :port: 11006 :persistent_delay: 1 :debug_log: true :environment: development :result_storage: memcache :memcache: "xxx.xxx.xxx.xxx:11211,xxx.xxx.xxx.xxx:11211" :client: "xxx.xxx.xxx.xxx:11006,xxx.xxx.xxx.xxx:11006" # :schedules: # optional task scheduling My worker: require 'hpricot' require 'open-uri' class TexisWorker < BackgrounDRb::MetaWorker set_worker_name :texis_worker pool_size 40 def create(args = nil) logger.info "Creating Texis Worker Instance" end def search(arg) thread_pool.defer(:perform_search, arg) end def perform_search(arg) # calls out to a server runs a search, gets parsed by hpricot and then caches the results persistent_job.finish! end end Thanks, Curtis From jnutting at gmail.com Fri Oct 10 08:12:44 2008 From: jnutting at gmail.com (Jack Nutting) Date: Fri, 10 Oct 2008 14:12:44 +0200 Subject: [Backgroundrb-devel] magical disappearing background processes! Message-ID: Hi all, I've been having trouble for a long time with backgroundrb processes that suddenly vanish without a trace. What happens is that at some point I discover that all the backgroundrb processes are suddenly gone. Nothing special is seen in any of the log files. This has happened intermittently for a long time, and I was hoping that upgrading to 1.0.4 would somehow help me out, but I seem to encounter the same problem. It happens infrequently, sometimes two-three times a week, sometimes not at all for several weeks. Yesterday it actually happened twice in ten minutes during a period when the server was heavily loaded, but that's unusual. Usually when it happens the server is not under a heavy load. Yesterday when it happened, I had the fortune of having a "top" log running in a terminal window, so I'm able to present some more data. top was displaying all threads, so most of the processes show up twice or more. I have 5 background workers running, each apparently has 2 threads, plus log_worker with 1 thread and script/backgroundrb with 2 threads. My architecture is set up so that only "master" is started automatically when backgroundrb starts up, and it in turn starts the rest. I'm pasting in data for all the backgroundrb processes, sorry for the terrible formatting but I can't really think of a better way to present this all. Here's what it normally looks like while everything is up and running. This is the last "normal" state I found before it starting going haywire: top - 15:11:13 up 5 days, 5:05, 3 users, load average: 3.10, 3.09, 3.02 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17508 deploy 15 0 49300 35m 2688 S 11.8 1.7 7:54.65 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 18:16:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar 17504 deploy 15 0 49648 35m 2688 S 8.2 1.7 8:01.64 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 16:14:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar 14141 deploy 15 0 20796 17m 1612 S 0.3 0.8 2:48.59 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 8:7:log_worker:17:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s 14147 deploy 15 0 48232 34m 2556 S 0.3 1.7 5:10.90 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri 17523 deploy 17 0 132m 115m 3316 R 0.3 5.6 6:43.89 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 20:18:campaign_starter:39:/home/deploy/mbargo/lib/workers:/home/deploy/ 14102 deploy 17 0 48320 31m 1364 R 0.0 1.5 3:08.97 ruby /home/deploy/mbargo/script/backgroundrb start 14144 deploy 15 0 48320 31m 1364 S 0.0 1.5 0:45.35 ruby /home/deploy/mbargo/script/backgroundrb start 17446 deploy 15 0 48232 34m 2556 S 0.0 1.7 0:43.62 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri 17486 deploy 15 0 59500 41m 3500 S 0.0 2.0 11:45.15 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 14:13:receiver:39:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s 22300 deploy 15 0 59500 41m 3500 S 0.0 2.0 0:45.27 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 14:13:receiver:39:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s 23636 deploy 15 0 49648 35m 2688 S 0.0 1.7 0:45.68 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 16:14:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar 24042 deploy 15 0 49300 35m 2688 S 0.0 1.7 0:43.58 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 18:16:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar 24053 deploy 15 0 132m 115m 3316 S 0.0 5.6 0:43.70 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 20:18:campaign_starter:39:/home/deploy/mbargo/lib/workers:/home/deploy/ Next snapshot, 3 seconds later. script/backgroundrb is gone, and each of my workers (except for master) is down to 1 thread. top - 15:11:16 up 5 days, 5:05, 3 users, load average: 3.10, 3.09, 3.02 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17504 deploy 15 0 49648 35m 2688 S 12.6 1.7 8:02.02 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 16:14:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar 17486 deploy 17 0 59500 41m 3500 R 0.3 2.0 11:45.16 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 14:13:receiver:39:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s 14141 deploy 15 0 20796 17m 1612 S 0.0 0.8 2:48.59 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 8:7:log_worker:17:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s 14147 deploy 15 0 48232 34m 2556 S 0.0 1.7 5:10.90 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri 17446 deploy 15 0 48232 34m 2556 S 0.0 1.7 0:43.62 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri 22300 deploy 15 0 59500 41m 3500 S 0.0 2.0 0:45.27 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 14:13:receiver:39:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s 23636 deploy 15 0 49648 35m 2688 S 0.0 1.7 0:45.68 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 16:14:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar Next, 3 seconds after that, all I have left is master (still 2 threads) and log_worker: top - 15:11:19 up 5 days, 5:05, 3 users, load average: 2.85, 3.03, 3.01 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14141 deploy 15 0 20796 17m 1612 S 0.0 0.8 2:48.59 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 8:7:log_worker:17:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s 14147 deploy 15 0 48232 34m 2556 S 0.0 1.7 5:10.90 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri 17446 deploy 15 0 48232 34m 2556 S 0.0 1.7 0:43.62 /usr/bin/ruby1.8 /usr/bin/packet_worker_runner 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri At the next snapshot, all backgroundrb processes are gone. This is running on Ubuntu 7.10, backgroundrb 1.0.4. I'm nowhere near maxing out system memory, and there are no memory or other limits set on user processes as far as I can tell. If anyone has any ideas about what might cause this, or how to dig deeper, please let me know! I'm nearly at my wits' end. -- // jack // http://www.nuthole.com From gethemant at gmail.com Fri Oct 10 08:34:24 2008 From: gethemant at gmail.com (hemant kumar) Date: Fri, 10 Oct 2008 18:04:24 +0530 Subject: [Backgroundrb-devel] magical disappearing background processes! In-Reply-To: References: Message-ID: <1223642064.24004.0.camel@shire> Are your running two copies of BackgrounDRb server on the same machine? I see, two server instances, in your top output. On Fri, 2008-10-10 at 14:12 +0200, Jack Nutting wrote: > Hi all, > > I've been having trouble for a long time with backgroundrb processes > that suddenly vanish without a trace. What happens is that at some > point I discover that all the backgroundrb processes are suddenly > gone. Nothing special is seen in any of the log files. This has > happened intermittently for a long time, and I was hoping that > upgrading to 1.0.4 would somehow help me out, but I seem to encounter > the same problem. > > It happens infrequently, sometimes two-three times a week, sometimes > not at all for several weeks. Yesterday it actually happened twice in > ten minutes during a period when the server was heavily loaded, but > that's unusual. Usually when it happens the server is not under a > heavy load. > > Yesterday when it happened, I had the fortune of having a "top" log > running in a terminal window, so I'm able to present some more data. > top was displaying all threads, so most of the processes show up twice > or more. > > I have 5 background workers running, each apparently has 2 threads, > plus log_worker with 1 thread and script/backgroundrb with 2 threads. > My architecture is set up so that only "master" is started > automatically when backgroundrb starts up, and it in turn starts the > rest. > > I'm pasting in data for all the backgroundrb processes, sorry for the > terrible formatting but I can't really think of a better way to > present this all. > > Here's what it normally looks like while everything is up and running. > This is the last "normal" state I found before it starting going > haywire: > > top - 15:11:13 up 5 days, 5:05, 3 users, load average: 3.10, 3.09, 3.02 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 17508 deploy 15 0 49300 35m 2688 S 11.8 1.7 7:54.65 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 18:16:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar > 17504 deploy 15 0 49648 35m 2688 S 8.2 1.7 8:01.64 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 16:14:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar > 14141 deploy 15 0 20796 17m 1612 S 0.3 0.8 2:48.59 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 8:7:log_worker:17:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s > 14147 deploy 15 0 48232 34m 2556 S 0.3 1.7 5:10.90 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri > 17523 deploy 17 0 132m 115m 3316 R 0.3 5.6 6:43.89 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 20:18:campaign_starter:39:/home/deploy/mbargo/lib/workers:/home/deploy/ > 14102 deploy 17 0 48320 31m 1364 R 0.0 1.5 3:08.97 ruby > /home/deploy/mbargo/script/backgroundrb start > 14144 deploy 15 0 48320 31m 1364 S 0.0 1.5 0:45.35 ruby > /home/deploy/mbargo/script/backgroundrb start > 17446 deploy 15 0 48232 34m 2556 S 0.0 1.7 0:43.62 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri > 17486 deploy 15 0 59500 41m 3500 S 0.0 2.0 11:45.15 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 14:13:receiver:39:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s > 22300 deploy 15 0 59500 41m 3500 S 0.0 2.0 0:45.27 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 14:13:receiver:39:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s > 23636 deploy 15 0 49648 35m 2688 S 0.0 1.7 0:45.68 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 16:14:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar > 24042 deploy 15 0 49300 35m 2688 S 0.0 1.7 0:43.58 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 18:16:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar > 24053 deploy 15 0 132m 115m 3316 S 0.0 5.6 0:43.70 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 20:18:campaign_starter:39:/home/deploy/mbargo/lib/workers:/home/deploy/ > > Next snapshot, 3 seconds later. script/backgroundrb is gone, and each > of my workers (except for master) is down to 1 thread. > > top - 15:11:16 up 5 days, 5:05, 3 users, load average: 3.10, 3.09, 3.02 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 17504 deploy 15 0 49648 35m 2688 S 12.6 1.7 8:02.02 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 16:14:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar > 17486 deploy 17 0 59500 41m 3500 R 0.3 2.0 11:45.16 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 14:13:receiver:39:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s > 14141 deploy 15 0 20796 17m 1612 S 0.0 0.8 2:48.59 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 8:7:log_worker:17:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s > 14147 deploy 15 0 48232 34m 2556 S 0.0 1.7 5:10.90 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri > 17446 deploy 15 0 48232 34m 2556 S 0.0 1.7 0:43.62 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri > 22300 deploy 15 0 59500 41m 3500 S 0.0 2.0 0:45.27 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 14:13:receiver:39:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s > 23636 deploy 15 0 49648 35m 2688 S 0.0 1.7 0:45.68 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 16:14:mblox_sender:94:/home/deploy/mbargo/lib/workers:/home/deploy/mbar > > Next, 3 seconds after that, all I have left is master (still 2 > threads) and log_worker: > > top - 15:11:19 up 5 days, 5:05, 3 users, load average: 2.85, 3.03, 3.01 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 14141 deploy 15 0 20796 17m 1612 S 0.0 0.8 2:48.59 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 8:7:log_worker:17:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/s > 14147 deploy 15 0 48232 34m 2556 S 0.0 1.7 5:10.90 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri > 17446 deploy 15 0 48232 34m 2556 S 0.0 1.7 0:43.62 > /usr/bin/ruby1.8 /usr/bin/packet_worker_runner > 11:10:master:4:/home/deploy/mbargo/lib/workers:/home/deploy/mbargo/scri > > At the next snapshot, all backgroundrb processes are gone. > > This is running on Ubuntu 7.10, backgroundrb 1.0.4. I'm nowhere near > maxing out system memory, and there are no memory or other limits set > on user processes as far as I can tell. If anyone has any ideas about > what might cause this, or how to dig deeper, please let me know! I'm > nearly at my wits' end. > From jnutting at gmail.com Fri Oct 10 08:52:50 2008 From: jnutting at gmail.com (Jack Nutting) Date: Fri, 10 Oct 2008 14:52:50 +0200 Subject: [Backgroundrb-devel] magical disappearing background processes! In-Reply-To: <1223642064.24004.0.camel@shire> References: <1223642064.24004.0.camel@shire> Message-ID: On Fri, Oct 10, 2008 at 2:34 PM, hemant kumar wrote: > Are your running two copies of BackgrounDRb server on the same machine? > I see, two server instances, in your top output. No, it's just one. The mode I was running "top" in showed one line for each thread. -- // jack // http://www.nuthole.com From gethemant at gmail.com Tue Oct 14 12:40:41 2008 From: gethemant at gmail.com (hemant) Date: Tue, 14 Oct 2008 22:10:41 +0530 Subject: [Backgroundrb-devel] [ANN] BackgrounDRb release 1.1 Message-ID: Hi folks, BackgrounDRb 1.1 has been release. A brief rundown of changes include: * Much better start/stop functioanlity for BackgrounDRb server daemon. Start/stop script should now detect running server and can handle cleanup of pids as necessary. * More Docs * Better logger functionality. * More test coverage (around 70%, use rake rcov) * Dynamically started workers should be immediately usable on Mac OSX now (needs packet 0.1.14) * Job migration table has been extracted as a seperate migration now. * Handled crashes in BackgrounDRb server daemon for invalid messages. For more information, visit: http://backgroundrb.rubyforge.org From akenger at gmail.com Wed Oct 15 13:15:25 2008 From: akenger at gmail.com (Adam Kenger) Date: Wed, 15 Oct 2008 13:15:25 -0400 Subject: [Backgroundrb-devel] Error starting Backgroundrb Message-ID: <600e8cd20810151015t6b68e732jff12095e0fd996f0@mail.gmail.com> Hi all. I'm hoping this is a really simple issue, but I've been scouring the web for a few hours and have come up with nothing. I am running the newest backgroundrb from git (1.1) on a Mac running Leopard. Environment below. I have installed packet 0.1.14 and chronic 0.2.3 as well as run the setup rake task (and made sure all my files in the script/ directory were cleaned out). When I start backgroundrb - /script/backgroundrb start I get the following in the debug log /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- log_worker (LoadError) from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `require' from /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:35:in `load_worker' from /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:26:in `initialize' from /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47:in `new' from /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47 from /usr/bin/packet_worker_runner:19:in `load' from /usr/bin/packet_worker_runner:19 The server is running, but when it tries to run one of my workers, it reports the same "no such file to load" error. Can anyone help out? Thanks in advance Adam Kenger ------------------------- RubyGems Environment: - RUBYGEMS VERSION: 1.2.0 - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org/", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org/ - http://gems.github.com *** LOCAL GEMS *** actionmailer (2.1.1, 2.1.0, 2.0.2, 1.3.6, 1.3.3) actionpack (2.1.1, 2.1.0, 2.0.2, 1.13.6, 1.13.5, 1.13.3) actionwebservice (1.2.6) activerecord (2.1.1, 2.1.0, 2.0.2, 1.15.6, 1.15.5, 1.15.3) activeresource (2.1.1, 2.1.0, 2.0.2) activesupport (2.1.1, 2.1.0, 2.0.2, 1.4.4, 1.4.2) acts_as_ferret (0.4.3, 0.4.1) adzap-ar_mailer (1.4.3) bcrypt-ruby (2.0.3, 2.0.2) capistrano (2.5.0, 2.4.3, 2.2.0, 2.1.0, 2.0.0) cgi_multipart_eof_fix (2.5.0) chronic (0.2.3) composite_primary_keys (0.9.93) daemons (1.0.10, 1.0.9) dnssd (0.7.0, 0.6.0) fastthread (1.0.1) fcgi (0.8.7) ferret (0.11.6, 0.11.4) gem_plugin (0.2.3) highline (1.4.0, 1.2.9) hoe (1.8.0, 1.7.0) hpricot (0.6.161, 0.6) libxml-ruby (0.8.3, 0.5.4, 0.5.2.0) linecache (0.43) mongrel (1.1.5, 1.1.4, 1.1.2) mysql (2.7) needle (1.3.0) net-scp (1.0.1) net-sftp (2.0.1, 1.1.1, 1.1.0) net-ssh (2.0.4, 2.0.3, 1.1.2) net-ssh-gateway (1.0.0) packet (0.1.14) rails (2.1.1, 2.1.0, 2.0.2, 1.2.6, 1.2.3) rake (0.8.3, 0.8.1, 0.7.3) RedCloth (4.0.4, 4.0.1, 3.0.4) ruby-debug-base (0.10.2, 0.10.1, 0.10.0) ruby-debug-ide (0.3.1, 0.2.0, 0.1.10) ruby-openid (2.1.2, 2.0.4, 2.0.1, 1.1.4) ruby-yadis (0.3.4) rubyforge (1.0.0) rubygems-update (1.3.0, 1.2.0, 1.1.1, 0.9.5) rubynode (0.1.5, 0.1.4, 0.1.3) sources (0.0.1) sqlite3-ruby (1.2.4, 1.2.2, 1.2.1) termios (0.9.4) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmillr at umich.edu Wed Oct 15 13:57:52 2008 From: jmillr at umich.edu (John Miller) Date: Wed, 15 Oct 2008 13:57:52 -0400 Subject: [Backgroundrb-devel] Error starting Backgroundrb In-Reply-To: <600e8cd20810151015t6b68e732jff12095e0fd996f0@mail.gmail.com> References: <600e8cd20810151015t6b68e732jff12095e0fd996f0@mail.gmail.com> Message-ID: <59E03406-DACE-4DCB-9298-D4CFAFF2E690@umich.edu> I reported a similar error on Leopard on Sept. 12th (check archives). Hemant suggested the following, which worked for me, but the context was running 'god': > Looks like, PATH is not proper when god is automatically starting it. > Check if "packet_worker_runner" script is in PATH.Its a executable, > that > packet installs when gem gets installed. I'm not sure where you'd set the PATH so packet_worker_runner can find your workers. Somehow, you want to add the /Library/Ruby/Gems/1.8/.../packet_worker_runner path somewhere. By the way, since you're on Leopard, you may have more luck running your own versions of ruby and rubygems by following these excellent instructions: http://hivelogic.com/articles/2008/02/ruby-rails-leopard John On Oct 15, 2008, at 1:15 PM, Adam Kenger wrote: > Hi all. I'm hoping this is a really simple issue, but I've been > scouring the web for a few hours and have come up with nothing. > > I am running the newest backgroundrb from git (1.1) on a Mac running > Leopard. Environment below. > > I have installed packet 0.1.14 and chronic 0.2.3 as well as run the > setup rake task (and made sure all my files in the script/ directory > were cleaned out). > > When I start backgroundrb - > > /script/backgroundrb start > > I get the following in the debug log > > /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in > `gem_original_require': no such file to load -- log_worker (LoadError) > from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in > `require' > from /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:35:in `load_worker' > from /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:26:in `initialize' > from /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:47:in `new' > from /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:47 > from /usr/bin/packet_worker_runner:19:in `load' > from /usr/bin/packet_worker_runner:19 > > The server is running, but when it tries to run one of my workers, > it reports the same "no such file to load" error. > > Can anyone help out? > > Thanks in advance > > Adam Kenger > > ------------------------- > > > > RubyGems Environment: > - RUBYGEMS VERSION: 1.2.0 > - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [universal- > darwin9.0] > - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 > - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/ > Versions/1.8/usr/bin/ruby > - EXECUTABLE DIRECTORY: /usr/bin > - RUBYGEMS PLATFORMS: > - ruby > - universal-darwin-9 > - GEM PATHS: > - /Library/Ruby/Gems/1.8 > - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/ > lib/ruby/gems/1.8 > - GEM CONFIGURATION: > - :update_sources => true > - :verbose => true > - :benchmark => false > - :backtrace => false > - :bulk_threshold => 1000 > - :sources => ["http://gems.rubyforge.org/", "http://gems.github.com > "] > - REMOTE SOURCES: > - http://gems.rubyforge.org/ > - http://gems.github.com > > > *** LOCAL GEMS *** > > actionmailer (2.1.1, 2.1.0, 2.0.2, 1.3.6, 1.3.3) > actionpack (2.1.1, 2.1.0, 2.0.2, 1.13.6, 1.13.5, 1.13.3) > actionwebservice (1.2.6) > activerecord (2.1.1, 2.1.0, 2.0.2, 1.15.6, 1.15.5, 1.15.3) > activeresource (2.1.1, 2.1.0, 2.0.2) > activesupport (2.1.1, 2.1.0, 2.0.2, 1.4.4, 1.4.2) > acts_as_ferret (0.4.3, 0.4.1) > adzap-ar_mailer (1.4.3) > bcrypt-ruby (2.0.3, 2.0.2) > capistrano (2.5.0, 2.4.3, 2.2.0, 2.1.0, 2.0.0) > cgi_multipart_eof_fix (2.5.0) > chronic (0.2.3) > composite_primary_keys (0.9.93) > daemons (1.0.10, 1.0.9) > dnssd (0.7.0, 0.6.0) > fastthread (1.0.1) > fcgi (0.8.7) > ferret (0.11.6, 0.11.4) > gem_plugin (0.2.3) > highline (1.4.0, 1.2.9) > hoe (1.8.0, 1.7.0) > hpricot (0.6.161, 0.6) > libxml-ruby (0.8.3, 0.5.4, 0.5.2.0) > linecache (0.43) > mongrel (1.1.5, 1.1.4, 1.1.2) > mysql (2.7) > needle (1.3.0) > net-scp (1.0.1) > net-sftp (2.0.1, 1.1.1, 1.1.0) > net-ssh (2.0.4, 2.0.3, 1.1.2) > net-ssh-gateway (1.0.0) > packet (0.1.14) > rails (2.1.1, 2.1.0, 2.0.2, 1.2.6, 1.2.3) > rake (0.8.3, 0.8.1, 0.7.3) > RedCloth (4.0.4, 4.0.1, 3.0.4) > ruby-debug-base (0.10.2, 0.10.1, 0.10.0) > ruby-debug-ide (0.3.1, 0.2.0, 0.1.10) > ruby-openid (2.1.2, 2.0.4, 2.0.1, 1.1.4) > ruby-yadis (0.3.4) > rubyforge (1.0.0) > rubygems-update (1.3.0, 1.2.0, 1.1.1, 0.9.5) > rubynode (0.1.5, 0.1.4, 0.1.3) > sources (0.0.1) > sqlite3-ruby (1.2.4, 1.2.2, 1.2.1) > termios (0.9.4) > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From gethemant at gmail.com Wed Oct 15 14:03:22 2008 From: gethemant at gmail.com (hemant) Date: Wed, 15 Oct 2008 23:33:22 +0530 Subject: [Backgroundrb-devel] Error starting Backgroundrb In-Reply-To: <600e8cd20810151015t6b68e732jff12095e0fd996f0@mail.gmail.com> References: <600e8cd20810151015t6b68e732jff12095e0fd996f0@mail.gmail.com> Message-ID: Did you remove both "backgroundrb" and "load_worker_env.rb" script from script directory of your rails app, before running "rake backgroundrb:setup" ? On Wed, Oct 15, 2008 at 10:45 PM, Adam Kenger wrote: > Hi all. I'm hoping this is a really simple issue, but I've been scouring > the web for a few hours and have come up with nothing. > I am running the newest backgroundrb from git (1.1) on a Mac running > Leopard. Environment below. > I have installed packet 0.1.14 and chronic 0.2.3 as well as run the setup > rake task (and made sure all my files in the script/ directory were cleaned > out). > When I start backgroundrb - > /script/backgroundrb start > I get the following in the debug log > /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in > `gem_original_require': no such file to load -- log_worker (LoadError) > from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in > `require' > from > /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:35:in > `load_worker' > from > /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:26:in > `initialize' > from > /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47:in > `new' > from > /Library/Ruby/Gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47 > from /usr/bin/packet_worker_runner:19:in `load' > from /usr/bin/packet_worker_runner:19 > The server is running, but when it tries to run one of my workers, it > reports the same "no such file to load" error. > Can anyone help out? > Thanks in advance > Adam Kenger > ------------------------- > > > RubyGems Environment: > - RUBYGEMS VERSION: 1.2.0 > - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0] > - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 > - RUBY EXECUTABLE: > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby > - EXECUTABLE DIRECTORY: /usr/bin > - RUBYGEMS PLATFORMS: > - ruby > - universal-darwin-9 > - GEM PATHS: > - /Library/Ruby/Gems/1.8 > - > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 > - GEM CONFIGURATION: > - :update_sources => true > - :verbose => true > - :benchmark => false > - :backtrace => false > - :bulk_threshold => 1000 > - :sources => ["http://gems.rubyforge.org/", "http://gems.github.com"] > - REMOTE SOURCES: > - http://gems.rubyforge.org/ > - http://gems.github.com > > *** LOCAL GEMS *** > actionmailer (2.1.1, 2.1.0, 2.0.2, 1.3.6, 1.3.3) > actionpack (2.1.1, 2.1.0, 2.0.2, 1.13.6, 1.13.5, 1.13.3) > actionwebservice (1.2.6) > activerecord (2.1.1, 2.1.0, 2.0.2, 1.15.6, 1.15.5, 1.15.3) > activeresource (2.1.1, 2.1.0, 2.0.2) > activesupport (2.1.1, 2.1.0, 2.0.2, 1.4.4, 1.4.2) > acts_as_ferret (0.4.3, 0.4.1) > adzap-ar_mailer (1.4.3) > bcrypt-ruby (2.0.3, 2.0.2) > capistrano (2.5.0, 2.4.3, 2.2.0, 2.1.0, 2.0.0) > cgi_multipart_eof_fix (2.5.0) > chronic (0.2.3) > composite_primary_keys (0.9.93) > daemons (1.0.10, 1.0.9) > dnssd (0.7.0, 0.6.0) > fastthread (1.0.1) > fcgi (0.8.7) > ferret (0.11.6, 0.11.4) > gem_plugin (0.2.3) > highline (1.4.0, 1.2.9) > hoe (1.8.0, 1.7.0) > hpricot (0.6.161, 0.6) > libxml-ruby (0.8.3, 0.5.4, 0.5.2.0) > linecache (0.43) > mongrel (1.1.5, 1.1.4, 1.1.2) > mysql (2.7) > needle (1.3.0) > net-scp (1.0.1) > net-sftp (2.0.1, 1.1.1, 1.1.0) > net-ssh (2.0.4, 2.0.3, 1.1.2) > net-ssh-gateway (1.0.0) > packet (0.1.14) > rails (2.1.1, 2.1.0, 2.0.2, 1.2.6, 1.2.3) > rake (0.8.3, 0.8.1, 0.7.3) > RedCloth (4.0.4, 4.0.1, 3.0.4) > ruby-debug-base (0.10.2, 0.10.1, 0.10.0) > ruby-debug-ide (0.3.1, 0.2.0, 0.1.10) > ruby-openid (2.1.2, 2.0.4, 2.0.1, 1.1.4) > ruby-yadis (0.3.4) > rubyforge (1.0.0) > rubygems-update (1.3.0, 1.2.0, 1.1.1, 0.9.5) > rubynode (0.1.5, 0.1.4, 0.1.3) > sources (0.0.1) > sqlite3-ruby (1.2.4, 1.2.2, 1.2.1) > termios (0.9.4) > > _______________________________________________ > 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 aneishaboori at socialvibe.com Wed Oct 22 17:22:13 2008 From: aneishaboori at socialvibe.com (Aslan Neishaboori) Date: Wed, 22 Oct 2008 14:22:13 -0700 Subject: [Backgroundrb-devel] error starting backgroundrb Message-ID: <3B14E8D7-5154-4E47-B0AB-2092D5934680@socialvibe.com> its been two days that i am struggling with this error. i have followed all the instructions in http://backgroundrb.rubyforge.org. when i start the server i get the following error 1. /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb: 27:in `gem_original_require': no such file to load -- task_alert_worker (LoadError) 2. from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/ custom_require.rb:27:in `require' 3. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ packet_worker_runner:35:in `load_worker' 4. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ packet_worker_runner:26:in `initialize' 5. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ packet_worker_runner:47:in `new' 6. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ packet_worker_runner:47 7. from /opt/local/bin/packet_worker_runner:19:in `load' 8. from /opt/local/bin/packet_worker_runner:19 9. /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb: 27:in `gem_original_require': no such file to load -- task_alert_worker (LoadError) 10. from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/ custom_require.rb:27:in `require' 11. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ packet_worker_runner:35:in `load_worker' 12. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ packet_worker_runner:26:in `initialize' 13. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ packet_worker_runner:47:in `new' 14. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ packet_worker_runner:47 15. from /opt/local/bin/packet_worker_runner:19:in `load' 16. from /opt/local/bin/packet_worker_runner:19 somewhere i read that this can be fixed by rolling back the packet gem to version 0.1.5. it did fix the start up problem but then when i call a worker from the console i get the following error which i guess has to do with the dependency. 1. /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/ active_support/dependencies.rb:279:in `load_missing_constant': uninitialized constant Packet::BinParser (NameError) 2. from /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/ active_support/dependencies.rb:468:in `const_missing' 3. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/server/lib/master_worker.rb:165:in `post_init' 4. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_connection.rb:21:in `invoke_init' 5. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:302:in `decorate_handler' 6. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:76:in `accept_connection' 7. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:202:in `handle_external_messages' 8. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:178:in `handle_read_event' 9. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:174:in `each' 10. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:174:in `handle_read_event' 11. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:130:in `start_reactor' 12. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:124:in `loop' 13. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:124:in `start_reactor' 14. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_master.rb:21:in `run' 15. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/server/lib/master_proxy.rb:14:in `initialize' 16. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `new' 17. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `start' 18. from ./script/backgroundrb:35 19. /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_nbio.rb:25:in `read_data': Packet::DisconnectError (Packet::DisconnectError) 20. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_worker.rb:46:in `handle_internal_messages' 21. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:176:in `handle_read_event' 22. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:174:in `each' 23. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:174:in `handle_read_event' 24. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:130:in `start_reactor' 25. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:124:in `loop' 26. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:124:in `start_reactor' 27. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_worker.rb:20:in `start_worker' 28. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_master.rb:133:in `fork_and_load' 29. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_master.rb:96:in `load_workers' 30. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_master.rb:91:in `each' 31. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_master.rb:91:in `load_workers' 32. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_master.rb:20:in `run' 33. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/server/lib/master_proxy.rb:14:in `initialize' 34. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `new' 35. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `start' 36. from ./script/backgroundrb:35 37. /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_nbio.rb:25:in `read_data': Packet::DisconnectError (Packet::DisconnectError) 38. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_worker.rb:46:in `handle_internal_messages' 39. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:176:in `handle_read_event' 40. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:174:in `each' 41. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:174:in `handle_read_event' 42. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:130:in `start_reactor' 43. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:124:in `loop' 44. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_core.rb:124:in `start_reactor' 45. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_worker.rb:20:in `start_worker' 46. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_master.rb:133:in `fork_and_load' 47. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_master.rb:108:in `start_worker' 48. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/server/lib/master_proxy.rb:16:in `initialize' 49. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ packet_master.rb:19:in `run' 50. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/server/lib/master_proxy.rb:14:in `initialize' 51. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `new' 52. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `start' 53. from ./script/backgroundrb:35 i am running os x. my gem versions : *** LOCAL GEMS *** actionmailer (2.1.1, 1.3.5) actionpack (2.1.1, 1.13.5) actionwebservice (1.2.5) activerecord (2.1.1, 1.15.5) activeresource (2.1.1) activesupport (2.1.1, 1.4.4) arrayfields (4.6.0) capistrano (2.5.0) capistrano-ext (1.2.1) cgi_multipart_eof_fix (2.5.0) cheat (1.2.1) chronic (0.2.3) daemons (1.0.10) eventmachine (0.12.2) fastercsv (1.4.0) fastthread (1.0.1) fattr (1.0.3) gem_plugin (0.2.3) git (1.0.5) git-rails (0.2.1) highline (1.4.0) hoe (1.7.0) hpricot (0.6.161) libxml-ruby (0.8.3) main (2.8.2) memcache-client (1.5.0) mongrel (1.1.5) mysql (2.7) net-scp (1.0.1) net-sftp (2.0.1) net-ssh (2.0.4) net-ssh-gateway (1.0.0) packet (0.1.14) rails (2.1.1, 1.2.5) rake (0.8.3) rubyforge (1.0.0) starling (0.9.8) SyslogLogger (1.4.0) ZenTest (3.10.0) by the way every time i changed something i removed ./script/ load_worker_env.rb and ./script/backgroundrb and ran rake backgroundrb:setup how can i fix this problem. aslan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gethemant at gmail.com Thu Oct 23 04:28:31 2008 From: gethemant at gmail.com (hemant) Date: Thu, 23 Oct 2008 13:58:31 +0530 Subject: [Backgroundrb-devel] error starting backgroundrb In-Reply-To: <3B14E8D7-5154-4E47-B0AB-2092D5934680@socialvibe.com> References: <3B14E8D7-5154-4E47-B0AB-2092D5934680@socialvibe.com> Message-ID: Were you upgrading from old version or fresh install? Try to reproduce the problem with a fresh rails application and send me the zipped copy, if it still doesn't work. Afaik, looks like "lib/workers" is not in path. Are you using config.pluigns directive in your rails application? On Thu, Oct 23, 2008 at 2:52 AM, Aslan Neishaboori wrote: > its been two days that i am struggling with this error. i have followed all > the instructions in http://backgroundrb.rubyforge.org. > > when i start the server i get the following error > > 1. /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require': no such file to load -- task_alert_worker > (LoadError) > 2. from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > 3. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:35:in > `load_worker' > 4. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:26:in > `initialize' > 5. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47:in > `new' > 6. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47 > 7. from /opt/local/bin/packet_worker_runner:19:in `load' > 8. from /opt/local/bin/packet_worker_runner:19 > 9. /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require': no such file to load -- task_alert_worker > (LoadError) > 10. from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > 11. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:35:in > `load_worker' > 12. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:26:in > `initialize' > 13. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47:in > `new' > 14. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47 > 15. from /opt/local/bin/packet_worker_runner:19:in `load' > 16. from /opt/local/bin/packet_worker_runner:19 > > > > somewhere i read that this can be fixed by rolling back the packet gem to > version 0.1.5. it did fix the start up problem but then when i call a worker > from the console i get the following error which i guess has to do with the > dependency. > > 1. > /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/dependencies.rb:279:in > `load_missing_constant': uninitialized constant Packet::BinParser > (NameError) > 2. from > /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/dependencies.rb:468:in > `const_missing' > 3. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/server/lib/master_worker.rb:165:in > `post_init' > 4. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_connection.rb:21:in > `invoke_init' > 5. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:302:in > `decorate_handler' > 6. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:76:in > `accept_connection' > 7. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:202:in > `handle_external_messages' > 8. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:178:in > `handle_read_event' > 9. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in > `each' > 10. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in > `handle_read_event' > 11. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in > `start_reactor' > 12. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in > `loop' > 13. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in > `start_reactor' > 14. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:21:in > `run' > 15. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/server/lib/master_proxy.rb:14:in > `initialize' > 16. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in > `new' > 17. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in > `start' > 18. from ./script/backgroundrb:35 > 19. > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_nbio.rb:25:in > `read_data': Packet::DisconnectError (Packet::DisconnectError) > 20. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:46:in > `handle_internal_messages' > 21. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:176:in > `handle_read_event' > 22. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in > `each' > 23. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in > `handle_read_event' > 24. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in > `start_reactor' > 25. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in > `loop' > 26. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in > `start_reactor' > 27. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:20:in > `start_worker' > 28. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:133:in > `fork_and_load' > 29. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:96:in > `load_workers' > 30. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:91:in > `each' > 31. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:91:in > `load_workers' > 32. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:20:in > `run' > 33. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/server/lib/master_proxy.rb:14:in > `initialize' > 34. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in > `new' > 35. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in > `start' > 36. from ./script/backgroundrb:35 > 37. > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_nbio.rb:25:in > `read_data': Packet::DisconnectError (Packet::DisconnectError) > 38. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:46:in > `handle_internal_messages' > 39. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:176:in > `handle_read_event' > 40. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in > `each' > 41. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in > `handle_read_event' > 42. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in > `start_reactor' > 43. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in > `loop' > 44. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in > `start_reactor' > 45. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:20:in > `start_worker' > 46. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:133:in > `fork_and_load' > 47. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:108:in > `start_worker' > 48. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/server/lib/master_proxy.rb:16:in > `initialize' > 49. from > /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:19:in > `run' > 50. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/server/lib/master_proxy.rb:14:in > `initialize' > 51. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in > `new' > 52. from /Users/aslan/Documents/Aptana > Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in > `start' > 53. from ./script/backgroundrb:35 > > > i am running os x. > my gem versions : > *** LOCAL GEMS *** > > actionmailer (2.1.1, 1.3.5) > actionpack (2.1.1, 1.13.5) > actionwebservice (1.2.5) > activerecord (2.1.1, 1.15.5) > activeresource (2.1.1) > activesupport (2.1.1, 1.4.4) > arrayfields (4.6.0) > capistrano (2.5.0) > capistrano-ext (1.2.1) > cgi_multipart_eof_fix (2.5.0) > cheat (1.2.1) > chronic (0.2.3) > daemons (1.0.10) > eventmachine (0.12.2) > fastercsv (1.4.0) > fastthread (1.0.1) > fattr (1.0.3) > gem_plugin (0.2.3) > git (1.0.5) > git-rails (0.2.1) > highline (1.4.0) > hoe (1.7.0) > hpricot (0.6.161) > libxml-ruby (0.8.3) > main (2.8.2) > memcache-client (1.5.0) > mongrel (1.1.5) > mysql (2.7) > net-scp (1.0.1) > net-sftp (2.0.1) > net-ssh (2.0.4) > net-ssh-gateway (1.0.0) > packet (0.1.14) > rails (2.1.1, 1.2.5) > rake (0.8.3) > rubyforge (1.0.0) > starling (0.9.8) > SyslogLogger (1.4.0) > ZenTest (3.10.0) > > by the way every time i changed something i removed > ./script/load_worker_env.rb and ./script/backgroundrb and ran > rake backgroundrb:setup > > how can i fix this problem. > > aslan > _______________________________________________ > 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 aneishaboori at socialvibe.com Thu Oct 23 19:43:19 2008 From: aneishaboori at socialvibe.com (Aslan Neishaboori) Date: Thu, 23 Oct 2008 16:43:19 -0700 Subject: [Backgroundrb-devel] error starting backgroundrb In-Reply-To: References: <3B14E8D7-5154-4E47-B0AB-2092D5934680@socialvibe.com> Message-ID: <6D741311-AE9A-4F72-8682-0D87AC82E654@socialvibe.com> > Hi Hemant > > This is a fresh new application with no code in it except the small > code i made to test backgroundrb. as you have actually pointed out i > did run a $: on the console and lib was there but no lib/workers > (with s). so that could be the reason but why is it not there and > how can i add it ? On Oct 23, 2008, at 1:28 AM, hemant wrote: > Were you upgrading from old version or fresh install? > > Try to reproduce the problem with a fresh rails application and send > me the zipped copy, if it still doesn't work. > > Afaik, looks like "lib/workers" is not in path. Are you using > config.pluigns directive in your rails application? > > > > On Thu, Oct 23, 2008 at 2:52 AM, Aslan Neishaboori > wrote: >> its been two days that i am struggling with this error. i have >> followed all >> the instructions in http://backgroundrb.rubyforge.org. >> >> when i start the server i get the following error >> >> 1. /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb: >> 27:in >> `gem_original_require': no such file to load -- task_alert_worker >> (LoadError) >> 2. from >> /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in >> `require' >> 3. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ >> packet_worker_runner:35:in >> `load_worker' >> 4. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ >> packet_worker_runner:26:in >> `initialize' >> 5. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ >> packet_worker_runner:47:in >> `new' >> 6. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ >> packet_worker_runner:47 >> 7. from /opt/local/bin/packet_worker_runner:19:in `load' >> 8. from /opt/local/bin/packet_worker_runner:19 >> 9. /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb: >> 27:in >> `gem_original_require': no such file to load -- task_alert_worker >> (LoadError) >> 10. from >> /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in >> `require' >> 11. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ >> packet_worker_runner:35:in >> `load_worker' >> 12. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ >> packet_worker_runner:26:in >> `initialize' >> 13. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ >> packet_worker_runner:47:in >> `new' >> 14. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ >> packet_worker_runner:47 >> 15. from /opt/local/bin/packet_worker_runner:19:in `load' >> 16. from /opt/local/bin/packet_worker_runner:19 >> >> >> >> somewhere i read that this can be fixed by rolling back the packet >> gem to >> version 0.1.5. it did fix the start up problem but then when i call >> a worker >> from the console i get the following error which i guess has to do >> with the >> dependency. >> >> 1. >> /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/ >> active_support/dependencies.rb:279:in >> `load_missing_constant': uninitialized constant Packet::BinParser >> (NameError) >> 2. from >> /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/ >> active_support/dependencies.rb:468:in >> `const_missing' >> 3. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/server/lib/master_worker.rb: >> 165:in >> `post_init' >> 4. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_connection.rb:21:in >> `invoke_init' >> 5. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:302:in >> `decorate_handler' >> 6. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:76:in >> `accept_connection' >> 7. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:202:in >> `handle_external_messages' >> 8. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:178:in >> `handle_read_event' >> 9. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:174:in >> `each' >> 10. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:174:in >> `handle_read_event' >> 11. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:130:in >> `start_reactor' >> 12. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:124:in >> `loop' >> 13. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:124:in >> `start_reactor' >> 14. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_master.rb:21:in >> `run' >> 15. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/server/lib/master_proxy.rb: >> 14:in >> `initialize' >> 16. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/ >> bdrb_start_stop.rb:50:in >> `new' >> 17. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/ >> bdrb_start_stop.rb:50:in >> `start' >> 18. from ./script/backgroundrb:35 >> 19. >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_nbio.rb:25:in >> `read_data': Packet::DisconnectError (Packet::DisconnectError) >> 20. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_worker.rb:46:in >> `handle_internal_messages' >> 21. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:176:in >> `handle_read_event' >> 22. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:174:in >> `each' >> 23. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:174:in >> `handle_read_event' >> 24. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:130:in >> `start_reactor' >> 25. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:124:in >> `loop' >> 26. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:124:in >> `start_reactor' >> 27. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_worker.rb:20:in >> `start_worker' >> 28. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_master.rb:133:in >> `fork_and_load' >> 29. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_master.rb:96:in >> `load_workers' >> 30. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_master.rb:91:in >> `each' >> 31. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_master.rb:91:in >> `load_workers' >> 32. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_master.rb:20:in >> `run' >> 33. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/server/lib/master_proxy.rb: >> 14:in >> `initialize' >> 34. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/ >> bdrb_start_stop.rb:50:in >> `new' >> 35. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/ >> bdrb_start_stop.rb:50:in >> `start' >> 36. from ./script/backgroundrb:35 >> 37. >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_nbio.rb:25:in >> `read_data': Packet::DisconnectError (Packet::DisconnectError) >> 38. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_worker.rb:46:in >> `handle_internal_messages' >> 39. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:176:in >> `handle_read_event' >> 40. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:174:in >> `each' >> 41. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:174:in >> `handle_read_event' >> 42. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:130:in >> `start_reactor' >> 43. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:124:in >> `loop' >> 44. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_core.rb:124:in >> `start_reactor' >> 45. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_worker.rb:20:in >> `start_worker' >> 46. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_master.rb:133:in >> `fork_and_load' >> 47. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_master.rb:108:in >> `start_worker' >> 48. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/server/lib/master_proxy.rb: >> 16:in >> `initialize' >> 49. from >> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ >> packet_master.rb:19:in >> `run' >> 50. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/server/lib/master_proxy.rb: >> 14:in >> `initialize' >> 51. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/ >> bdrb_start_stop.rb:50:in >> `new' >> 52. from /Users/aslan/Documents/Aptana >> Studio/play/vendor/plugins/backgroundrb/lib/backgroundrb/ >> bdrb_start_stop.rb:50:in >> `start' >> 53. from ./script/backgroundrb:35 >> >> >> i am running os x. >> my gem versions : >> *** LOCAL GEMS *** >> >> actionmailer (2.1.1, 1.3.5) >> actionpack (2.1.1, 1.13.5) >> actionwebservice (1.2.5) >> activerecord (2.1.1, 1.15.5) >> activeresource (2.1.1) >> activesupport (2.1.1, 1.4.4) >> arrayfields (4.6.0) >> capistrano (2.5.0) >> capistrano-ext (1.2.1) >> cgi_multipart_eof_fix (2.5.0) >> cheat (1.2.1) >> chronic (0.2.3) >> daemons (1.0.10) >> eventmachine (0.12.2) >> fastercsv (1.4.0) >> fastthread (1.0.1) >> fattr (1.0.3) >> gem_plugin (0.2.3) >> git (1.0.5) >> git-rails (0.2.1) >> highline (1.4.0) >> hoe (1.7.0) >> hpricot (0.6.161) >> libxml-ruby (0.8.3) >> main (2.8.2) >> memcache-client (1.5.0) >> mongrel (1.1.5) >> mysql (2.7) >> net-scp (1.0.1) >> net-sftp (2.0.1) >> net-ssh (2.0.4) >> net-ssh-gateway (1.0.0) >> packet (0.1.14) >> rails (2.1.1, 1.2.5) >> rake (0.8.3) >> rubyforge (1.0.0) >> starling (0.9.8) >> SyslogLogger (1.4.0) >> ZenTest (3.10.0) >> >> by the way every time i changed something i removed >> ./script/load_worker_env.rb and ./script/backgroundrb and ran >> rake backgroundrb:setup >> >> how can i fix this problem. >> >> aslan >> _______________________________________________ >> 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 aneishaboori at socialvibe.com Fri Oct 24 14:00:03 2008 From: aneishaboori at socialvibe.com (Aslan Neishaboori) Date: Fri, 24 Oct 2008 11:00:03 -0700 Subject: [Backgroundrb-devel] error starting backgroundrb In-Reply-To: <600e8cd20810241022w694b7448iabf24cfbae5b9a8a@mail.gmail.com> References: <3B14E8D7-5154-4E47-B0AB-2092D5934680@socialvibe.com> <600e8cd20810241022w694b7448iabf24cfbae5b9a8a@mail.gmail.com> Message-ID: <7636605F-0781-40A5-B95F-777A54524A9E@socialvibe.com> Hi Adam... following is what i got. Hemant told me to check to see if the lib/ workers is loaded into the path. I ran the $: on console and didnt see it there. anyways let me know if find a solution. thanks Aslan Macintosh-8:~ aslan$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.2.0 - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://gems.rubyforge.org/ On Oct 24, 2008, at 10:22 AM, Adam Kenger wrote: > Aslan - can you do a $>gem env at the command prompt and paste the > output? I fought a lot with this myself a couple weeks ago (similar > error - no such file to load) and traded a bunch of emails with > Hemant and it turns out that I don't think this package works too > well with the default ruby installation done from Apple. Below is > my environment which I could NOT get working at all on my Mac. I > decided that since my production env. wasn't going to be my mac but > a Linux machine with a slightly different release of Ruby and Gems, > as long as it worked there, that was good enough for me. The > environment that Hemant used to do all the testing on OS X was a > custom ruby installation. > > Hope that helps > > Adam > > ------------------- > > RubyGems Environment: > - RUBYGEMS VERSION: 1.2.0 > - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [universal- > darwin9.0] > - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 > - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/ > Versions/1.8/usr/bin/ruby > - EXECUTABLE DIRECTORY: /usr/bin > - RUBYGEMS PLATFORMS: > - ruby > - universal-darwin-9 > - GEM PATHS: > - /Library/Ruby/Gems/1.8 > - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/ > lib/ruby/gems/1.8 > - GEM CONFIGURATION: > - :update_sources => true > - :verbose => true > - :benchmark => false > - :backtrace => false > - :bulk_threshold => 1000 > - :sources => ["http://gems.rubyforge.org/", "http://gems.github.com > "] > - REMOTE SOURCES: > - http://gems.rubyforge.org/ > - http://gems.github.com > > > On Wed, Oct 22, 2008 at 5:22 PM, Aslan Neishaboori > wrote: > its been two days that i am struggling with this error. i have > followed all the instructions in http://backgroundrb.rubyforge.org. > > when i start the server i get the following error > > 1. /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb: > 27:in `gem_original_require': no such file to load -- > task_alert_worker (LoadError) > 2. from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/ > custom_require.rb:27:in `require' > 3. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:35:in `load_worker' > 4. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:26:in `initialize' > 5. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:47:in `new' > 6. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:47 > 7. from /opt/local/bin/packet_worker_runner:19:in `load' > 8. from /opt/local/bin/packet_worker_runner:19 > 9. /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb: > 27:in `gem_original_require': no such file to load -- > task_alert_worker (LoadError) > 10. from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/ > custom_require.rb:27:in `require' > 11. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:35:in `load_worker' > 12. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:26:in `initialize' > 13. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:47:in `new' > 14. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ > packet_worker_runner:47 > 15. from /opt/local/bin/packet_worker_runner:19:in `load' > 16. from /opt/local/bin/packet_worker_runner:19 > > > > somewhere i read that this can be fixed by rolling back the packet > gem to version 0.1.5. it did fix the start up problem but then when > i call a worker from the console i get the following error which i > guess has to do with the dependency. > > 1. /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/ > active_support/dependencies.rb:279:in `load_missing_constant': > uninitialized constant Packet::BinParser (NameError) > 2. from /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/ > lib/active_support/dependencies.rb:468:in `const_missing' > 3. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/server/lib/master_worker.rb:165:in `post_init' > 4. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_connection.rb:21:in `invoke_init' > 5. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:302:in `decorate_handler' > 6. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:76:in `accept_connection' > 7. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:202:in `handle_external_messages' > 8. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:178:in `handle_read_event' > 9. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:174:in `each' > 10. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:174:in `handle_read_event' > 11. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:130:in `start_reactor' > 12. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:124:in `loop' > 13. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:124:in `start_reactor' > 14. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_master.rb:21:in `run' > 15. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/server/lib/master_proxy.rb:14:in `initialize' > 16. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `new' > 17. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `start' > 18. from ./script/backgroundrb:35 > 19. /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ > packet_nbio.rb:25:in `read_data': Packet::DisconnectError > (Packet::DisconnectError) > 20. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_worker.rb:46:in `handle_internal_messages' > 21. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:176:in `handle_read_event' > 22. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:174:in `each' > 23. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:174:in `handle_read_event' > 24. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:130:in `start_reactor' > 25. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:124:in `loop' > 26. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:124:in `start_reactor' > 27. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_worker.rb:20:in `start_worker' > 28. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_master.rb:133:in `fork_and_load' > 29. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_master.rb:96:in `load_workers' > 30. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_master.rb:91:in `each' > 31. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_master.rb:91:in `load_workers' > 32. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_master.rb:20:in `run' > 33. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/server/lib/master_proxy.rb:14:in `initialize' > 34. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `new' > 35. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `start' > 36. from ./script/backgroundrb:35 > 37. /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ > packet_nbio.rb:25:in `read_data': Packet::DisconnectError > (Packet::DisconnectError) > 38. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_worker.rb:46:in `handle_internal_messages' > 39. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:176:in `handle_read_event' > 40. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:174:in `each' > 41. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:174:in `handle_read_event' > 42. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:130:in `start_reactor' > 43. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:124:in `loop' > 44. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_core.rb:124:in `start_reactor' > 45. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_worker.rb:20:in `start_worker' > 46. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_master.rb:133:in `fork_and_load' > 47. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_master.rb:108:in `start_worker' > 48. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/server/lib/master_proxy.rb:16:in `initialize' > 49. from /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/ > packet/packet_master.rb:19:in `run' > 50. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/server/lib/master_proxy.rb:14:in `initialize' > 51. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `new' > 52. from /Users/aslan/Documents/Aptana Studio/play/vendor/plugins/ > backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in `start' > 53. from ./script/backgroundrb:35 > > > i am running os x. > my gem versions : > *** LOCAL GEMS *** > > actionmailer (2.1.1, 1.3.5) > actionpack (2.1.1, 1.13.5) > actionwebservice (1.2.5) > activerecord (2.1.1, 1.15.5) > activeresource (2.1.1) > activesupport (2.1.1, 1.4.4) > arrayfields (4.6.0) > capistrano (2.5.0) > capistrano-ext (1.2.1) > cgi_multipart_eof_fix (2.5.0) > cheat (1.2.1) > chronic (0.2.3) > daemons (1.0.10) > eventmachine (0.12.2) > fastercsv (1.4.0) > fastthread (1.0.1) > fattr (1.0.3) > gem_plugin (0.2.3) > git (1.0.5) > git-rails (0.2.1) > highline (1.4.0) > hoe (1.7.0) > hpricot (0.6.161) > libxml-ruby (0.8.3) > main (2.8.2) > memcache-client (1.5.0) > mongrel (1.1.5) > mysql (2.7) > net-scp (1.0.1) > net-sftp (2.0.1) > net-ssh (2.0.4) > net-ssh-gateway (1.0.0) > packet (0.1.14) > rails (2.1.1, 1.2.5) > rake (0.8.3) > rubyforge (1.0.0) > starling (0.9.8) > SyslogLogger (1.4.0) > ZenTest (3.10.0) > > by the way every time i changed something i removed ./script/ > load_worker_env.rb and ./script/backgroundrb and ran > rake backgroundrb:setup > > how can i fix this problem. > > aslan > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From synfinatic at gmail.com Mon Oct 27 01:19:32 2008 From: synfinatic at gmail.com (Aaron Turner) Date: Sun, 26 Oct 2008 22:19:32 -0700 Subject: [Backgroundrb-devel] Performance problems running Prawn under BackgrounDRb Message-ID: <1ca1c1410810262219h3303f3d6p236613b0d3dc953c@mail.gmail.com> I have a RoR application which I'm using Prawn via BackgrounDRb to generate PDF's. I've determined there seems to be a 5-6x performance hit compared to running Prawn directly as a script from the command line (~12sec to 60+sec) on my OS X system. Anyone have any suggestions on how to improve performance? -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin From gethemant at gmail.com Mon Oct 27 23:04:15 2008 From: gethemant at gmail.com (hemant) Date: Tue, 28 Oct 2008 08:34:15 +0530 Subject: [Backgroundrb-devel] Performance problems running Prawn under BackgrounDRb In-Reply-To: <1ca1c1410810262219h3303f3d6p236613b0d3dc953c@mail.gmail.com> References: <1ca1c1410810262219h3303f3d6p236613b0d3dc953c@mail.gmail.com> Message-ID: On Mon, Oct 27, 2008 at 10:49 AM, Aaron Turner wrote: > I have a RoR application which I'm using Prawn via BackgrounDRb to > generate PDF's. I've determined there seems to be a 5-6x performance > hit compared to running Prawn directly as a script from the command > line (~12sec to 60+sec) on my OS X system. > > Anyone have any suggestions on how to improve performance? Hi Aaron, 1. How are you benchmarking this? 2. Are you using thread pool? 3. If you do not need large thread pool, you can reduce size using "thread_pool 1", which will give some boost in performance because having 20 threads active inside interpretor is a performance penalty. From synfinatic at gmail.com Tue Oct 28 17:33:14 2008 From: synfinatic at gmail.com (Aaron Turner) Date: Tue, 28 Oct 2008 14:33:14 -0700 Subject: [Backgroundrb-devel] Performance problems running Prawn under BackgrounDRb In-Reply-To: References: <1ca1c1410810262219h3303f3d6p236613b0d3dc953c@mail.gmail.com> Message-ID: <1ca1c1410810281433t6452b3ffqc5e380c463613071@mail.gmail.com> On Mon, Oct 27, 2008 at 8:04 PM, hemant wrote: > On Mon, Oct 27, 2008 at 10:49 AM, Aaron Turner wrote: >> I have a RoR application which I'm using Prawn via BackgrounDRb to >> generate PDF's. I've determined there seems to be a 5-6x performance >> hit compared to running Prawn directly as a script from the command >> line (~12sec to 60+sec) on my OS X system. >> >> Anyone have any suggestions on how to improve performance? > > Hi Aaron, > > 1. How are you benchmarking this? > 2. Are you using thread pool? > 3. If you do not need large thread pool, you can reduce size using > "thread_pool 1", which will give some boost in performance because > having 20 threads active inside interpretor is a performance penalty. > I tried the thread_pool thing, it helped a little, but backgroundrb is still multiple times slower then running the same code from a ruby script. Anyways, I created a standalone rails app which showcases this problem: http://synfin.net/code/prawn_demo.tar.gz I put some info in the README, but if you have any further questions let me know. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin From synfinatic at gmail.com Wed Oct 29 02:16:40 2008 From: synfinatic at gmail.com (Aaron Turner) Date: Tue, 28 Oct 2008 23:16:40 -0700 Subject: [Backgroundrb-devel] Performance problems running Prawn under BackgrounDRb In-Reply-To: References: <1ca1c1410810262219h3303f3d6p236613b0d3dc953c@mail.gmail.com> <1ca1c1410810281433t6452b3ffqc5e380c463613071@mail.gmail.com> Message-ID: <1ca1c1410810282316hf5bff90we2e9511e775377f7@mail.gmail.com> On Tue, Oct 28, 2008 at 10:39 PM, hemant wrote: > On Wed, Oct 29, 2008 at 3:03 AM, Aaron Turner wrote: >> On Mon, Oct 27, 2008 at 8:04 PM, hemant wrote: >>> On Mon, Oct 27, 2008 at 10:49 AM, Aaron Turner wrote: >>>> I have a RoR application which I'm using Prawn via BackgrounDRb to >>>> generate PDF's. I've determined there seems to be a 5-6x performance >>>> hit compared to running Prawn directly as a script from the command >>>> line (~12sec to 60+sec) on my OS X system. >>>> >>>> Anyone have any suggestions on how to improve performance? >>> >>> Hi Aaron, >>> >>> 1. How are you benchmarking this? >>> 2. Are you using thread pool? >>> 3. If you do not need large thread pool, you can reduce size using >>> "thread_pool 1", which will give some boost in performance because >>> having 20 threads active inside interpretor is a performance penalty. >>> >> >> I tried the thread_pool thing, it helped a little, but backgroundrb is >> still multiple times slower then running the same code from a ruby >> script. Anyways, I created a standalone rails app which showcases >> this problem: >> >> http://synfin.net/code/prawn_demo.tar.gz >> > > Hey there, > > two things: > > 1. I see you are passing a lot of data around (the whole YAML dump). > Can you not just pass some id or some other key, which can be used to > read the data in worker and populate the object? That will speed up > things by fair margin. That could be done, but my testing shows that the startup cost of passing all the data from RoR to backgroundrb is insignificant compared to the time spent in the while loop processing it in Prawn. > 2. That update() hack is ugly. You got to use cache object of bdrb, > make sure you are using memcache backend there. > > http://backgroundrb.rubyforge.org/workers/#result_caching That's a good suggestion. I'll have to start using memcache. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin From gethemant at gmail.com Wed Oct 29 01:39:07 2008 From: gethemant at gmail.com (hemant) Date: Wed, 29 Oct 2008 11:09:07 +0530 Subject: [Backgroundrb-devel] Performance problems running Prawn under BackgrounDRb In-Reply-To: <1ca1c1410810281433t6452b3ffqc5e380c463613071@mail.gmail.com> References: <1ca1c1410810262219h3303f3d6p236613b0d3dc953c@mail.gmail.com> <1ca1c1410810281433t6452b3ffqc5e380c463613071@mail.gmail.com> Message-ID: On Wed, Oct 29, 2008 at 3:03 AM, Aaron Turner wrote: > On Mon, Oct 27, 2008 at 8:04 PM, hemant wrote: >> On Mon, Oct 27, 2008 at 10:49 AM, Aaron Turner wrote: >>> I have a RoR application which I'm using Prawn via BackgrounDRb to >>> generate PDF's. I've determined there seems to be a 5-6x performance >>> hit compared to running Prawn directly as a script from the command >>> line (~12sec to 60+sec) on my OS X system. >>> >>> Anyone have any suggestions on how to improve performance? >> >> Hi Aaron, >> >> 1. How are you benchmarking this? >> 2. Are you using thread pool? >> 3. If you do not need large thread pool, you can reduce size using >> "thread_pool 1", which will give some boost in performance because >> having 20 threads active inside interpretor is a performance penalty. >> > > I tried the thread_pool thing, it helped a little, but backgroundrb is > still multiple times slower then running the same code from a ruby > script. Anyways, I created a standalone rails app which showcases > this problem: > > http://synfin.net/code/prawn_demo.tar.gz > Hey there, two things: 1. I see you are passing a lot of data around (the whole YAML dump). Can you not just pass some id or some other key, which can be used to read the data in worker and populate the object? That will speed up things by fair margin. 2. That update() hack is ugly. You got to use cache object of bdrb, make sure you are using memcache backend there. http://backgroundrb.rubyforge.org/workers/#result_caching Thats for now. I will get back, once I get to see things more closely.