[Backgroundrb-devel] Problems with async worker request

hemant gethemant at gmail.com
Mon Sep 8 13:46:05 EDT 2008


This is one known bug/issue which shows up only on Mac OSX. I haven't
had time to chase this thing (mostly because I don't have a Mac
machine for testing), but behaviour is, for a newly spawned worker, it
takes sometime before worker becomes usable.

I am very sorry about this and will try to fix on next possible
chance(time), btw this whole thing works flawlessly on Linux.


On Mon, Sep 8, 2008 at 9:56 PM, Brent Collier <brentmc79 at gmail.com> wrote:
> Sorry if this comes through twice.  I already sent this once, before joining
> the mailing list.
>
> I'm attempting to use Backgroundrb to handle asynchronous pdf creation, but
> in doing so, I've run into a very strange problem.  Below is a method that's
> called from the controller which creates a new worker, then grabs the worker
> and calls the 'build_pdf' method asynchronously.
>
>   def make_pdf(template_path, worker_key)
>     with_empty_asset_id do
>       html_string = render_to_string(:template => template_path, :layout =>
> 'pdf')
>       key = MiddleMan.new_worker(:worker => :prince_xml_worker, :worker_key
> => worker_key)
>       MiddleMan.worker(:prince_xml_worker, key).async_build_pdf(:arg =>
> html_string)
>     end
>   end
>
> Then there's another method which polls the worker like so.
>
>   def ask_worker_status(worker_key)
>     MiddleMan.worker(:prince_xml_worker, worker_key).ask_result(:pdf)
>   end
>
> It didn't seem to be working properly, so I started doing a little
> debugging.  Suddenly, it worked!  So I removed my debugger statements and
> tried again.  It stopped working.  I kept going back and forth like this,
> trying differnet scenarios, poking at the workers, and checking their
> results.  Finally, I narrowed it down to one debugger statement in the
> make_pdf method.
>
>   def make_pdf(template_path, worker_key)
>     with_empty_asset_id do
>       html_string = render_to_string(:template => template_path, :layout =>
> 'pdf')
>       key = MiddleMan.new_worker(:worker => :prince_xml_worker, :worker_key
> => worker_key)
>       worker = MiddleMan.worker(:prince_xml_worker, key)
>>>    debugger
>       worker.async_build_pdf(:arg => html_string)
>     end
>   end
>
> When that debugger statement is in the code, everything works perfectly.
> When it hits the debugger during the request, it doesn't matter whether I
> poke around at a few objects, or just continue immediately.  I even tried
> replacing the 'debugger' with a 'sleep(1)' and everything worked perfectly.
> When I removed the sleep call, no worky.
>
> If I look at the backgroundrb_debug_11006 log, I see "Client disconnected"
> each time the app polls the worker, and occasionally, I see this:
>
> Packet::InvalidWorker
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_connection.rb:52:in
> `ask_worker'
> /Users/brent/near-time/near-time.net-exp-rescue-princexml-5504/vendor/plugins/backgroundrb/server/lib/master_worker.rb:123:in
> `get_result_object'
> /Users/brent/near-time/near-time.net-exp-rescue-princexml-5504/vendor/plugins/backgroundrb/server/lib/master_worker.rb:39:in
> `receive_data'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_parser.rb:44:in
> `extract'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_parser.rb:26:in
> `loop'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_parser.rb:26:in
> `extract'
> /Users/brent/near-time/near-time.net-exp-rescue-princexml-5504/vendor/plugins/backgroundrb/server/lib/master_worker.rb:32:in
> `receive_data'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_core.rb:228:in
> `read_external_socket'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_core.rb:220:in
> `handle_external_messages'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_core.rb:194:in
> `handle_read_event'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_core.rb:190:in
> `each'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_core.rb:190:in
> `handle_read_event'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_core.rb:144:in
> `start_reactor'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_core.rb:137:in
> `loop'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_core.rb:137:in
> `start_reactor'
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.10/lib/packet/packet_master.rb:21:in
> `run'
> /Users/brent/near-time/near-time.net-exp-rescue-princexml-5504/vendor/plugins/backgroundrb/server/lib/master_proxy.rb:14:in
> `initialize'
> script/backgroundrb:46:in `new'
> script/backgroundrb:46
>
> This doesn't make much sense, and I'm at a loss.  Does anybody have any clue
> what might be going on here?
>
> FYI - I'm on the latest (as of this morning) git version of backgroundrb.
>
> thanks,
> -Brent
>
> --
> Brent Collier |  www.acts-as-blogr.com
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>



-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org


More information about the Backgroundrb-devel mailing list