New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
backpressure is broken #28
Comments
@chemhack which version of node? I'm guessing you're running the latest node-spdyproxy (from master)...? |
node v0.8.23 yes, node-spdyproxy from master |
Can you try 0.10+? We've had similar reports in the past which seems to have gone away after upgrade - see #21. |
Update: This issue was observed in HTTP and HTTPS download. |
Update again: It has already been fixed 6 days ago by @indutny After back porting this commit to 1.5.0, the backpressure is working. @igrigorik Why not update to newer version of node-spdy? Do you have a plan for this? @indutny Can you release a 1.5.1 version of node-spdy on npm with commit spdy-http2/node-spdy@be33b5a patched as a temporary fix? |
I'm happy to bump the version.. |
Oh, that's nice :) Didn't realize that this could be a problem for Cheers, On Mon, May 20, 2013 at 6:38 AM, Ilya Grigorik notifications@github.comwrote:
|
@igrigorik How is going? I still didn't see version 1.5.1 of node-spdy. And node-spdyproxy has compatible issue with 1.8.x |
@chemhack node-spdy v1.8.8 is up on NPM, so in theory as long as you install that, node-spdyproxy should work just fine.. I'm not sure where the 1.5.x requirement came from? |
@igrigorik The problem is node-spdyproxy doesn't work with node-spdy 1.8.8. 1.5.0 just worked fine. |
Oh, well then.. That's the actual problem we need to fix, instead of releasing 1.5.1. |
Ok, testing locally, I believe spdy-http2/node-spdy#95 should fix the problem. /cc @indutny |
Recently I found that node eat a huge amount of memory in my production servers. After a brief test by downloading a 100M binary file I found this:
This is very clear that backpressure is broken. I have no idea why it happens as stream.pipe() should already handled that. It looks like the underlying node-spdy's problem. I.e. the 'drain' event of underlying socket was not propagate to the response stream.
Issue #24 may be related to this.
@indutny any ideas?
The text was updated successfully, but these errors were encountered: