Hongli Lai

Hm, you are right. The passenger_max_request_time timer starts _after_ a process has been selected for routing, not before. Now that I think about it, 'max request time' may not be...

We've recently had a discussion with an Enterprise customer about a similar problem. They are on Heroku, and whenever they deploy a new version, Heroku would spin up an instance,...

I've been researching the `poll()` system call. It might be possible to use POLLHUP to detect early disconnections. On OS X, POLLHUP seems to do what I want. On Linux,...

We have received a vote from an Enterprise customer for this feature. His use case is that they're getting traffic too quickly, so their requests are filling up in the...

Some progress has been made towards this today. The goal is to be able to detect early client disconnections by 5.0.26 so that we can forward half-closing events to Node.js...

This looks like an issue triggered in the Passenger native extension. What happens if you remove the native extension and have it recompiled? Try this: rm -rf /home/ruby/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/passenger-5.3.7/buildout/ruby passenger-config build-native-support

Thanks for submitting the pull request @ROMB. I'm wondering what other effects there are of removing that code. What will happen to the buffering behavior on the Nginx side?

The hypothesized problem turned out to be a red herring. The real cause is much simpler, as is the solution. See #1322.

I will release 4.0.56 anyway, which contains #1322. That should at least help you guys in the short term.

_From [honglilai](https://code.google.com/u/[email protected]/) on June 23, 2009 02:14:13_ **Labels:** -Type-Defect Type-Enhancement