Brent Collier
2008-Sep-08 16:26 UTC
[Backgroundrb-devel] Problems with async worker request
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)>> debuggerworker.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080908/2676f339/attachment.html>
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
Brent Collier
2008-Sep-08 18:02 UTC
[Backgroundrb-devel] Problems with async worker request
Yep, I''m on OSX. Well, I guess that solves it. Thanks for the quick response guys! -Brent On Mon, Sep 8, 2008 at 1:46 PM, hemant <gethemant at gmail.com> wrote:> 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 >-- Brent Collier | www.acts-as-blogr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080908/d52fae5f/attachment.html>