[Backgroundrb-devel] Problems with async worker request

Brent Collier
Mon, 08 Sep 2008 18:02:11 -0000

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>