[Backgroundrb-devel] Problems with async worker request

hemant
Mon, 08 Sep 2008 17:46:05 -0000

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.