Rails - Jun 2006 - 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 Maddox wrote:
> 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/
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> 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/