Using DRb within Rails

I want to use DRb within my Rails app. Right now I’ve got a very basic
class:

class PaymentGateway
cattr_accessor :ssl_config, :host, :port

def self.gateway
@@gateway ||= new
end

def process(amount, card, type = :auth)
@biller.process(amount, card, type)
end

def set_card(user_id, number)
@biller.set_card(user_id, number)
end

protected
def initialize
DRb.start_service nil, nil, PaymentGateway.ssl_config
@biller = DRbObject.new(nil,
“drbssl://#{PaymentGateway.host}:#{PaymentGateway.port}”)
end
end

In my environment.rb file, I set up the config options. For
development/testing I’ve set up a mock class so it doesn’t actually
have to use DRb. In my code, I just do
gateway = PaymentGateway.gateway
gateway.set_card(1, “12345678”)

Can you see any problems this would present? I’ve tested it out a bit
on my dev box actually using DRb, and it seems to work fine. I just
don’t know what kind of issues might pop up, if any. I’m not talking
about stuff like what to do if the service isn’t available, because
that’s easy enough to check and handle. Not entirely sure what might
happen, so I’m just asking if anyone knows of stuff I should look out
for.

I know that you can use DRb within Rails, because Ezra’s backgroundrb
plugin [1] uses it. That presents another problem…after I get this
basic DRb use handled, I may want to use the backgroundrb plugin so
that I can run this remote process in the background and not tie up my
FCGI listeners. Can I run DRb code within backgroundrb, or is that
getting too complex to handle?

Pat

[1] http://backgroundrb.rubyforge.org/

Hi Pat!

On Jun 7, 2006, at 2:56 AM, Pat M. wrote:

def process(amount, card, type = :auth)
@biller = DRbObject.new(nil,
Can you see any problems this would present? I’ve tested it out a bit
that I can run this remote process in the background and not tie up my
http://lists.rubyonrails.org/mailman/listinfo/rails
You can certainly connect to other drb servers from within a
backgroundrb worker class. DRb is actually prewtty flexible with this
type of stuff. You can have drb servers and clients in the same
objects if you like. It just gets a bit complex to manage it when you
have trees of distributed objects like that.

I am working on a new feature for backgroundrb that will let your

worker classes spawn external processes that get controlled via drb
and talk back and forth with a heartbeat so when your worker class
gets deleted or gc’ed the next time a slave process tries to
heartbeat with your worker it will fail and therefor kill itself so
you don’t get zombied processes. I hope to have time to implement
this before railsconf so stay tuned. FOr now you might want to look
at the slave[1] library. It is what I plan on using so that your
worker classes can have their own slaves.

BackgrounDRb now has its own mailing list as well if you want to

join up:

http://rubyforge.org/mailman/listinfo/backgroundrb-devel

Cheers-
-Ezra

[1] http://codeforpeople.com/lib/ruby/slave/