merb

Comments and changes to this ticket

• 

  Michael Klishin (antares) July 16th, 2008 @ 09:42 PM

  1. render_deferred is a Mongrel-only thing. What adapter are you running?

  2. You probably mixed up render_deferred and render_then_call.

• 

  hanuman July 16th, 2008 @ 10:00 PM

  1. Yep, I am using mongrel, other adapters say streaming not supported.

  2. Nope, Make test action as suggested in example. Open two browser tabs, request action in first tab, switch quickly to second tab and request again same action.

  Then switch to screen where you started merb and check output.

  First request is processed and logged, second request is not processed and logged until first one is finished. So, actually render_deferred blocks all future calls for same action. And whole point of render_deferred is not to block anything, but to release lock as soon as possible.

  I am using render_deffered to generate pngs. I have page with 20 pngs which all call same action. Pngs are generated one by by one. Not good.

  Because of this bug, I need to make 10 different actions that do same thing and call them randomly. Then it doesn't block.

  I don't need render_then_call, I didn't even try that.

• 

  Michael Klishin (antares) July 16th, 2008 @ 10:05 PM

  • → Assigned user changed from “” to “Michael Klishin (antares)”
  • → Milestone changed from “” to “0.9.4”
  • → State changed from “new” to “open”

  Thanks for quick reply, investigating.

• 

  Michael Klishin (antares) August 2nd, 2008 @ 06:54 PM

  • → Milestone changed from “0.9.4” to “0.9.7”
• 

  Michael Klishin (antares) August 12th, 2008 @ 07:58 PM

  • → Milestone changed from “0.9.7” to “0.9.5”
• 

  Michael Klishin (antares) August 17th, 2008 @ 06:28 PM

  Did some investigation today and it turns out that lock option of Merb does not help with this.

• 

  Michael Klishin (antares) August 17th, 2008 @ 07:01 PM

  One more update: if you access two different actions (for instance I test with one action doing chunked rendering of Merb log and other using code you provided), Mongrel does not block.

• 

  Fabien Franzen (loob2) August 18th, 2008 @ 04:09 PM

  I've done some investigation as well using Michael Klishin's sample app located at git://github.com/michaelklishin/render-deferred.git - I wasn't able to reproduce the blocking behaviour at all. My setup:

  Ruby 1.8.6 (2007-09-23 patchlevel 110) [i686-darwin9.1.1] Mongrel 1.1.5 Merb HEAD

  I've attached my results as a file.

  • deferred-results.txt 1.3 KB
• 

  Michael Klishin (antares) August 19th, 2008 @ 12:34 PM

  • → State changed from “open” to “invalid”

  Closing because the behavior Fabien described was reproduced on a number of machines now. If you have any details or suggestions, please, leave a comment.

• 

  Max Aller August 24th, 2008 @ 09:54 PM

  I was able to repro this bug, but then I decided I should do a git pull just to be on the safe side since I hadn't done so in a few days (< 1 week). And what do you know, I can no longer repro the bug since doing so. So, I think this bug was around, but it's recently been fixed.

• 

  netshade September 10th, 2008 @ 12:58 AM

  In 0.9.6, I have this behavior.

  Controller:

  def some_action render_deferred do

  t = Thread.start do
    # stuff
    sleep(@some_arbitrary_amount || 30)
  end
  t.join
  render "content"
  
  

  end end

  Multiple calls to this action block each other.

  As a side note, I tried bypassing this by refactoring the action to work w/ other servers (Thin, Turbo::Thin, Thin threaded, Evented Mongrel), and I got the same behavior every time.

• 

  netshade September 10th, 2008 @ 12:59 AM

  Addendum to above:

  ruby 1.8.6 (2007-09-24 patchlevel 111) [i486-linux]

• 

  Michael Klishin (antares) September 10th, 2008 @ 01:01 AM

  If possible, add deferred actions list in init file and route for that action.

  If you can put together some sample app on github, it's very welcome.

• 

  netshade September 10th, 2008 @ 06:53 PM

  Quick summary of below: not a bug, in my case I've found it to be browser behavior.

  I put together a very simple sample app here: http://github.com/netshade/rende...

  Using FF3, I would access an action by the same URL in two separate tabs, and watch my log output. It was clearly blocking - one action would return, and then the second would respond.

  However, when I tried to recreate this using wget, I did not see the behavior. I saw what I expected to see, that is, two requests starting at near the same time, and finishing at the same time.

  In this case, I believe FF3 blocks the request of an identical URL request if it's already requesting that URL. I tested this by requesting a blocking URL, and then the same URL suffixing the pointless ?foo=bar to the URL. I then saw the desired behavior, using FF3 as the browser.

  So: sorry for wasting your time Michael. I post the info here just in case anyone else runs into the same behavior.