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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > [email protected] > > 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
_______________________________________________ Backgroundrb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/backgroundrb-devel
