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