[Backgroundrb-devel] Problems with async worker request

Brent Collier brentmc79 at gmail.com
Mon Sep 8 14:02:11 EDT 2008


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>


More information about the Backgroundrb-devel mailing list