[Backgroundrb-devel] Connection to backgroundrb is lost when exiting action method

Ezra Zygmuntowicz ezmobius at gmail.com
Sun Sep 24 20:30:35 EDT 2006


Hey Omer-

	I guess I don't understand what you are trying to do? Why do you  
want to define your workers in the environemnt.rb? Your workers need  
to go into lib/workers for them to get picked up by the drb server.  
And I think the issue you are seeing is because you are confusing  
which side the workers run on. The reason the workers quit when the  
action is done is that raisl throws away the controller objects and  
makes new ones on each request. And your workers defined in env.rb  
are on the rails side of things and not actually running in the drb  
server like you think they are ;)


	You are going to get into trouble trying to define your workers in  
env.rb like that. Just put them in lib/workers. You can dynamically  
generate them, in there if you want and they will get loaded into the  
drb server.

	Backgroundrb kinda straddles the line between the drb server and  
your rails apps. SO it is easy to get confused about where things are  
running.



-Ezra


On Sep 24, 2006, at 5:00 PM, Omer Enbar wrote:

> So do we have any ideas what goes wrong?
> Once again, here are the details:
> 1. Backgroundrb runs smoothly.
> 2. I define the worker dynamically in environment.rb both in bdrb and
> in the server.
> 3. If I execute the worker from environment.rb it runs forever  
> perfectly.
> 4. If I run the worker from an action, it runs perfectly as long as
> the action doesn't return.
>
> Why would it run if I execute the worker from environment.rb forever,
> but only as long as the action scope is active when running it from
> the action?
>
> Omer.
>
> ---------- Forwarded message ----------
> From: Omer Enbar <omer.enbar at gmail.com>
> Date: Sep 24, 2006 11:47 AM
> Subject: Re: [Backgroundrb-devel] Connection to backgroundrb is lost
> when exiting action method
> To: Ezra Zygmuntowicz <ezmobius at gmail.com>
> Cc: backgroundrb-devel at rubyforge.org
>
>
> Hey Ezra.
>
> I just wanted to use a nice way to define workers like 'run_every
> 5.minutes {block}' :)
> Why can't I do it that way if I define it both in backgroundrb and the
> server? bdrb does load the definitions and it does run...
>
> Anyway, if there is no way to do it like this, I'll just write the
> workers statically.
>
> Omer.
>
> On 9/24/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>> Hey Omer-
>>
>>         Ok I see your problem. You don;t want the workers to be  
>> defined in
>> environment.rb like that, its not the way bdrb works. The workers are
>> required into the drb server when it starts and not on the rails side
>> of things. Can you explain what it is you are trying to accomplish
>> and why you need to dynamically create the worker class like that?
>> I;m curious and maybe I can help you come up with a better way of
>> doing this.
>>
>>         Also the next release of backgroundrb is coming soon ™ ;)  
>> And now it
>> uses multiple processes instead of running workers in one
>> multithreaded ruby process. This makes it much much more scalable and
>> also keeps the same interface!
>>
>>
>> -Ezra
>>
>>
>>
>> On Sep 24, 2006, at 12:32 AM, Omer Enbar wrote:
>>
>> > Hey.
>> >
>> > I've got this in environment.rb:
>> >
>> > # define a worker class on the run with 'run_every 1.second,  
>> method'
>> > # in backgroundrb there's only definition, while in the server  
>> it is
>> > being spawned
>> > def run_every delta, meth, singleton = true
>> >  worker_class_name = "Worker#{Digest::SHA1.hexdigest(meth.to_s)}"
>> >  if not Object.constants.member? worker_class_name
>> >    Object.class_eval <<-METHOD_CODE
>> >        class #{worker_class_name} < BackgrounDRb::Rails
>> >
>> >         repeat_every #{delta}
>> >         first_run Time.now
>> >
>> >          def do_work(args)
>> >            log :debug, "\#{Time.now} running: \#{args[:name]}"
>> >            args[:method].call
>> >          rescue => e
>> >            puts "\#{e}"
>> > #            kill
>> >          end
>> >        end
>> > METHOD_CODE
>> >    puts worker_class_name
>> >  end
>> >  MiddleMan.new_worker(:class => worker_class_name,
>> >                       :singleton => singleton,
>> >                       :args => {:method => meth, :name =>  
>> meth.to_s})
>> > unless $0 =~ /backgroundrb/
>> > end
>> >
>> > def blah
>> >  puts "blah!"
>> > end
>> >
>> > def run_workers
>> >  run_every 1.second, Object.method(:blah)
>> > rescue DRb::DRbConnError
>> >  run_backgroundrb
>> > end
>> >
>> >
>> > Now I have an action, support /localhost/test/drb
>> >
>> > def drb
>> >   run_workers
>> >   sleep 5
>> > end
>> >
>> > When I run the action, I'll start seeing 'blah' for 5 seconds, and
>> > once the execution leaves method drb, I'll have a connection error
>> > druby://localhost:42531 - #<Errno::EBADF: Bad file descriptor -
>> > connect(2)
>> > as printed in the body of the worker.
>> >
>> > Thanks for the quick reply.
>> > Omer.
>> >
>> >
>> > On 9/24/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>> >> Hey Omer-
>> >>
>> >> On Sep 23, 2006, at 11:03 AM, Omer Enbar wrote:
>> >>
>> >> > Hey.
>> >> >
>> >> > I have a very annoying problem, and was wondering what is wrong.
>> >> > Suppose I have backgroundrb running, and then I have an action
>> >> in some
>> >> > controller. In the action I define a worker. When leaving the
>> >> action,
>> >> > suddenly the connection to backgroundrb is lost:
>> >> > DRb URI: druby://localhost:22222
>> >> > Pid: 3976
>> >> > Autostart...
>> >> > done
>> >> > druby://localhost:42531 - #<Errno::EBADF: Bad file descriptor -
>> >> > connect(2)>
>> >> > druby://localhost:42531 - #<Errno::EBADF: Bad file descriptor -
>> >> > connect(2)>
>> >> > ...
>> >> >
>> >> > When I'm still in the action, for instance using 'sleep 10'. As
>> >> long
>> >> > I'm inside the action, there's no problem with the worker.
>> >> >
>> >> > Why is that?
>> >> > Why would the connection to the worker be lost?
>> >> >
>> >> >
>> >> > Thanks,
>> >> > Omer.
>> >>
>> >>         Can you paste the code in question? I am not sure what you
>> >> are
>> >> trying to do that is causing you trouble.
>> >>
>> >> -Ezra
>> >>
>>
>>



More information about the Backgroundrb-devel mailing list