[Backgroundrb-devel] :job_key acting weird?

Stephen Weiss sweiss at stylesight.com
Sun Dec 31 00:49:05 EST 2006


Hey,

Just reading through the digests and I found this.  I'm experiencing  
a very similar thing, also on Mac OS X Tiger (Server or normal  
Client, Server is production and 10.4 client is my development/test  
server - same results on both)

I found that the following class names would not start, no matter what:

ChatTesterWorker
ImageToWebProcessorWorker
CTWorker

using :class => :chat_test_worker, :image_to_web_processor_worker,  
or :c_t_worker - all of which produce the correct class names

However, these alternative class names, with the same exact code,  
would work fine:

TestWorker
WebProcessorWorker
DoThisWorker

These are two different classes (I tried ChatTesterWorker as CTWorker  
as well) with different code, both that have the same problem where  
they will fail with particular names.  They just simply don't run -  
they return a job key and then they never even show up in the process  
list.  No errors, nothing logged - even if the only thing in the code  
is a logger.info call.

As far as job keys, I found almost always an explicit job key will  
fail for me... the only one I've gotten to work successfully  
is :chat, although I've only tried a few... I think :notifier did not  
work for me, and :batcher did not work either.

I use ruby 1.8.5 (and I'm sure I'm not accidentally using the version  
that comes with Tiger, I've fully deleted it off the systems), rails  
1.1.6, backgroundrb 2.1.

Another thing that's still happening is that you can't seem to call  
another worker from inside a rails worker.  I have a chat  
notification worker that uses xmpp4r.  It works fine when called  
directly from rails via my User model.  Here is the code for the  
ChatNotificationWorker class:
---
require 'xmpp4r'
class ChatNotificationWorker < BackgrounDRb::Worker::Base
   #  Results worker completely does not work for me as described in  
the README,
   #  but using attr_reader methods still works just fine for getting  
progress and error messages
   attr_reader :error_msg
   def do_work(params)
   @error_msg  = ""
     begin
       @client = Jabber::Client.new(Jabber::JID.new 
('race at my_chat_server/Rails'))
       @myPassword = 'my_password'
       @client.connect
       @client.auth_nonsasl(@myPassword, false)

     rescue
         @error_msg  = $!.to_s
     end
   end
   def notify(params)
       to = params[:address]
       body = params[:message]
       subject = "Automated Message"
       m = Jabber::Message::new(to, body).set_type(:normal).set_id 
(Time.now.to_s).set_subject(subject)
       @client.send(m)
   end
end
ChatNotificationWorker.register
---

And the method from the User model class:
---
def notify_by_chat(message)
     begin
       if self.chat_address && self.chat_address.include?("@")
         MiddleMan.worker(:chat).notify(:address =>  
self.chat_address, :message => message)
       else
         logger.info("no chat address for #{self.name}")
       end
     rescue
       logger.info("The following error was thrown:")
       logger.info($!.to_s)
     end
end
---
There is a separate method to start the chat worker, since autostart  
doesn't seem to function right.  That part works fine.

If, from within rails, I call for instance User.find(7).notify_by_chat 
("message"), everything goes right and I get a chat message as expected.

If, however, from within a different RailsBase worker, I call the  
exact same code, I get nothing:
---
class DoThisWorker < BackgrounDRb::Worker::RailsBase

def do_work(args)
    User.find(7).notify_by_chat("message")
end

end
DoThisWorker.register
---

If I use script/backgroundrb run, I see:
---
/usr/local/lib/ruby/1.8/drb/drb.rb:612: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [powerpc-darwin8.7.2]

undefined method `wait' for nil:NilClass - (NoMethodError)
/web/trunk/vendor/plugins/backgroundrb/server/lib/backgroundrb/ 
middleman.rb:217:in `new_worker'
/web/trunk/vendor/plugins/backgroundrb/server/lib/backgroundrb/ 
thread_pool.rb:36:in `dispatch'
/web/trunk/vendor/plugins/backgroundrb/server/lib/backgroundrb/ 
thread_pool.rb:22:in `initialize'
/web/trunk/vendor/plugins/backgroundrb/server/lib/backgroundrb/ 
thread_pool.rb:22:in `new'
/web/trunk/vendor/plugins/backgroundrb/server/lib/backgroundrb/ 
thread_pool.rb:22:in `dispatch'
/web/trunk/vendor/plugins/backgroundrb/server/lib/backgroundrb/ 
middleman.rb:199:in `new_worker'
/usr/local/lib/ruby/1.8/drb/drb.rb:1555:in `__send__'
/usr/local/lib/ruby/1.8/drb/drb.rb:1555:in `perform_without_block'
/usr/local/lib/ruby/1.8/drb/drb.rb:1515:in `perform'
/usr/local/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop'
/usr/local/lib/ruby/1.8/drb/drb.rb:1585:in `loop'
/usr/local/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop'
/usr/local/lib/ruby/1.8/drb/drb.rb:1581:in `start'
/usr/local/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop'
/usr/local/lib/ruby/1.8/drb/drb.rb:1430:in `run'
/usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `start'
/usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run'
/usr/local/lib/ruby/1.8/drb/drb.rb:1347:in `initialize'
/usr/local/lib/ruby/1.8/drb/drb.rb:1627:in `new'
/usr/local/lib/ruby/1.8/drb/drb.rb:1627:in `start_service'
/web/trunk/vendor/plugins/backgroundrb/server/lib/ 
backgroundrb_server.rb:314:in `run'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/ 
application.rb:186:in `call'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/ 
application.rb:186:in `start_proc'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/ 
application.rb:196:in `call'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/ 
application.rb:196:in `start_proc'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/ 
application.rb:226:in `start'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/ 
controller.rb:72:in `run'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in  
`run_proc'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/ 
cmdline.rb:94:in `call'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/ 
cmdline.rb:94:in `catch_exceptions'
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:178:in  
`run_proc'
/web/trunk/vendor/plugins/backgroundrb/server/lib/ 
backgroundrb_server.rb:301:in `run'
script/backgroundrb:29
---

Which, again, looks surprisingly similar to the error from Ivo,  
although with the Segmentation Fault on top.  Very discouraging.

If I call it from rails using work_thread like so:

MiddleMan.worker(:chat).work_thread(:method => :notify, :args =>  
{:address => self.chat_address, :message => message})

It also fails with the same segmentation fault and nil.wait error.

This *did* work with version 1, however version 1 leaves all sorts of  
db connections laying around so I'd much rather stick with version  
2.x, which otherwise works great!  However, chat notifications are  
mainly useful for these background jobs, and not so much directly  
from rails, so I really would like to fix this.  Any thoughts as to a  
better way for a worker to send a chat message without having to  
start up its own chat session?  It would seem to make sense to use  
one separate worker to do all the chatting, since it cuts down on  
excess connections.

Any suggestions would be appreciated!  Thanks for all your hard work  
guys, happy new year!

--
Steve

> Hi all
>
> I'm experiencing something strange with a :job_key, it took me a very
> long time to find out a worker wasn't doing it's job because of the
> name of my job_key. The first one I tried was :make_kohier, and with
> that name (and lot's of other ones) I can't get the worker to work. I
> do get my key in return, but the job doesn't start (the worker only
> had a logger.info method in it, no error there). As I can't see any
> results of this logger, and I can't delete the worker, the worker
> doesn't exist.
> I couldn't find the fault until I started changing the name of the
> job_key. I can't see any rules in it, some examples :job_key
> => :sdlkfskdsld doesn't work, :job_key => :skj does. :udjzkzis
> and :ssdlfdo don't work, :ssdlfdk does work.
> Just now I discovered that these keys sometimes work, sometimes
> not... Anyway, I only get errors if I run script/backgroundrb run,
> otherwise, there is nothing informing me of some error. Here is what
> I get in backgroundrb run
>
> [system: Mac OS X Tiger]
>
> You have a nil object when you didn't expect it!
> The error occured while evaluating nil.wait - (NoMethodError)

> {snip}
>

> Am I missing something here?
> Thanks for reading
> Ivo


More information about the Backgroundrb-devel mailing list