* Mongrel 2.0 @ 2008-11-17 20:32 Evan Weaver [not found] ` <b6f68fc60811171232s46ba20ebh19ff2d499494622d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 14+ messages in thread From: Evan Weaver @ 2008-11-17 20:32 UTC (permalink / raw) To: Mongrel Development Hi Mongrels, I'm working on trunk and would like to change the following things and release it as a 2.0rc. - Timestamped logging - 1.9.1rc compatibility - Early PID drop - Error code instead of connection-close, as discussed earlier - Option to fork and run from a shared socket on Linux instead of queueing - Move to a Rack handler interface, and include backwards-compatible versions of the current ones - Eliminate gem_plugins - Other random bugfixes from off the trac and github I'm unsure of what to do about mongrel_cluster. Do people still use that? Only for the --clean option? It would be nice if it could go away. At a later date, I would like to include optional ESI parsing to help people's dev environments. Please fuss at me if these are bad. Evan -- Evan Weaver ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <b6f68fc60811171232s46ba20ebh19ff2d499494622d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Mongrel 2.0 [not found] ` <b6f68fc60811171232s46ba20ebh19ff2d499494622d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2008-11-17 20:33 ` Evan Weaver [not found] ` <b6f68fc60811171233y7f103da0od5e875007f153f15-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-18 5:36 ` Zed A. Shaw ` (2 subsequent siblings) 3 siblings, 1 reply; 14+ messages in thread From: Evan Weaver @ 2008-11-17 20:33 UTC (permalink / raw) To: Mongrel Development Also, I will document the release process. Evan On Mon, Nov 17, 2008 at 3:32 PM, Evan Weaver <evan-72XWLPH10WVXUHR/Jj/Uug@public.gmane.org> wrote: > Hi Mongrels, > > I'm working on trunk and would like to change the following things and > release it as a 2.0rc. > > - Timestamped logging > - 1.9.1rc compatibility > - Early PID drop > - Error code instead of connection-close, as discussed earlier > - Option to fork and run from a shared socket on Linux instead of queueing > - Move to a Rack handler interface, and include backwards-compatible > versions of the current ones > - Eliminate gem_plugins > - Other random bugfixes from off the trac and github > > I'm unsure of what to do about mongrel_cluster. Do people still use > that? Only for the --clean option? It would be nice if it could go > away. > > At a later date, I would like to include optional ESI parsing to help > people's dev environments. > > Please fuss at me if these are bad. > > Evan > > -- > Evan Weaver > -- Evan Weaver ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <b6f68fc60811171233y7f103da0od5e875007f153f15-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Mongrel 2.0 [not found] ` <b6f68fc60811171233y7f103da0od5e875007f153f15-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2008-11-17 20:47 ` Ezra Zygmuntowicz [not found] ` <B99E038D-E0E5-43D1-8DCA-08957639F2CF-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 14+ messages in thread From: Ezra Zygmuntowicz @ 2008-11-17 20:47 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw These all look good to me. If you move the --clean option into mongrel proper then we no longer need mongrel_cluster afaik. Cheers- -Ezra On Nov 17, 2008, at 12:33 PM, Evan Weaver wrote: > Also, I will document the release process. > > Evan > > On Mon, Nov 17, 2008 at 3:32 PM, Evan Weaver <evan-72XWLPH10WVXUHR/Jj/Uug@public.gmane.org> wrote: >> Hi Mongrels, >> >> I'm working on trunk and would like to change the following things >> and >> release it as a 2.0rc. >> >> - Timestamped logging >> - 1.9.1rc compatibility >> - Early PID drop >> - Error code instead of connection-close, as discussed earlier >> - Option to fork and run from a shared socket on Linux instead of >> queueing >> - Move to a Rack handler interface, and include backwards-compatible >> versions of the current ones >> - Eliminate gem_plugins >> - Other random bugfixes from off the trac and github >> >> I'm unsure of what to do about mongrel_cluster. Do people still use >> that? Only for the --clean option? It would be nice if it could go >> away. >> >> At a later date, I would like to include optional ESI parsing to help >> people's dev environments. >> >> Please fuss at me if these are bad. >> >> Evan >> >> -- >> Evan Weaver >> > > > > -- > Evan Weaver > _______________________________________________ > Mongrel-development mailing list > Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org > http://rubyforge.org/mailman/listinfo/mongrel-development Ezra Zygmuntowicz ez-NLltGlunAUd/unjJdyJNww@public.gmane.org ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <B99E038D-E0E5-43D1-8DCA-08957639F2CF-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Mongrel 2.0 [not found] ` <B99E038D-E0E5-43D1-8DCA-08957639F2CF-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2008-11-17 22:55 ` Filipe Lautert 0 siblings, 0 replies; 14+ messages in thread From: Filipe Lautert @ 2008-11-17 22:55 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw Someone is doing dev work? whow Nice mate, go ahead! I can help after the first rc to find bugs/close them. Cheers filipe Ezra Zygmuntowicz wrote: > > These all look good to me. If you move the --clean option into > mongrel proper then we no longer need mongrel_cluster afaik. > > Cheers- > -Ezra > > > On Nov 17, 2008, at 12:33 PM, Evan Weaver wrote: > >> Also, I will document the release process. >> >> Evan >> >> On Mon, Nov 17, 2008 at 3:32 PM, Evan Weaver <evan-72XWLPH10WVXUHR/Jj/Uug@public.gmane.org> wrote: >>> Hi Mongrels, >>> >>> I'm working on trunk and would like to change the following things and >>> release it as a 2.0rc. >>> >>> - Timestamped logging >>> - 1.9.1rc compatibility >>> - Early PID drop >>> - Error code instead of connection-close, as discussed earlier >>> - Option to fork and run from a shared socket on Linux instead of >>> queueing >>> - Move to a Rack handler interface, and include backwards-compatible >>> versions of the current ones >>> - Eliminate gem_plugins >>> - Other random bugfixes from off the trac and github >>> >>> I'm unsure of what to do about mongrel_cluster. Do people still use >>> that? Only for the --clean option? It would be nice if it could go >>> away. >>> >>> At a later date, I would like to include optional ESI parsing to help >>> people's dev environments. >>> >>> Please fuss at me if these are bad. >>> >>> Evan >>> >>> -- >>> Evan Weaver >>> >> >> >> >> -- >> Evan Weaver >> _______________________________________________ >> Mongrel-development mailing list >> Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org >> http://rubyforge.org/mailman/listinfo/mongrel-development > > Ezra Zygmuntowicz > ez-NLltGlunAUd/unjJdyJNww@public.gmane.org > > > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org > http://rubyforge.org/mailman/listinfo/mongrel-development ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Mongrel 2.0 [not found] ` <b6f68fc60811171232s46ba20ebh19ff2d499494622d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-17 20:33 ` Evan Weaver @ 2008-11-18 5:36 ` Zed A. Shaw 2008-11-18 5:49 ` Evan Weaver 2008-11-18 14:59 ` Kirk Haines 2008-11-20 3:09 ` Luis Lavena 2008-12-06 0:48 ` Eric Wong 3 siblings, 2 replies; 14+ messages in thread From: Zed A. Shaw @ 2008-11-18 5:36 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw Very cool, nice work. One small comment... On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: > Hi Mongrels, > > - Error code instead of connection-close, as discussed earlier With this do you mean returning one of the many error codes in an HTTP response when the server is overloaded? I would recommend against that if that's the case. In theory it's nice to return an error code to clients that could be waiting. In practice, your queue is already overloaded, so taking more time to send a response to clients only adds to the problem. In a modern system this isn't such a big deal, but in Ruby it becomes a mess because of the file id limits in the select loop. I'd say, if you add that, make it optional to turn it off and be prepared with a FAQ about it in case people have problems. Have fun. -- Zed A. Shaw http://freehackersunion.org/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Mongrel 2.0 2008-11-18 5:36 ` Zed A. Shaw @ 2008-11-18 5:49 ` Evan Weaver [not found] ` <b6f68fc60811172149i5d0c8261ldba15c02212d6a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-18 14:59 ` Kirk Haines 1 sibling, 1 reply; 14+ messages in thread From: Evan Weaver @ 2008-11-18 5:49 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw Optional is a good compromise. Evan On Tue, Nov 18, 2008 at 12:36 AM, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote: > Very cool, nice work. One small comment... > > On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >> Hi Mongrels, >> >> - Error code instead of connection-close, as discussed earlier > > With this do you mean returning one of the many error codes in an HTTP > response when the server is overloaded? > > I would recommend against that if that's the case. In theory it's nice > to return an error code to clients that could be waiting. In practice, > your queue is already overloaded, so taking more time to send a response > to clients only adds to the problem. In a modern system this isn't such > a big deal, but in Ruby it becomes a mess because of the file id limits > in the select loop. > > I'd say, if you add that, make it optional to turn it off and be > prepared with a FAQ about it in case people have problems. > > Have fun. > > -- > Zed A. Shaw > http://freehackersunion.org/ > _______________________________________________ > Mongrel-development mailing list > Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org > http://rubyforge.org/mailman/listinfo/mongrel-development > -- Evan Weaver ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <b6f68fc60811172149i5d0c8261ldba15c02212d6a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Mongrel 2.0 [not found] ` <b6f68fc60811172149i5d0c8261ldba15c02212d6a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2008-11-20 2:31 ` Wayne Seguin 0 siblings, 0 replies; 14+ messages in thread From: Wayne Seguin @ 2008-11-20 2:31 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw Evan, I believe that optional with default being to drop the connection would be best in this case. It will serve the 98% case just fine and for those who are more demanding they can opt in. The rest look like a good set for a 2.0 release to me. ~Wayne On Nov 18, 2008, at 00:49 , Evan Weaver wrote: > Optional is a good compromise. > > Evan > > On Tue, Nov 18, 2008 at 12:36 AM, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> > wrote: >> Very cool, nice work. One small comment... >> >> On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >>> Hi Mongrels, >>> >>> - Error code instead of connection-close, as discussed earlier >> >> With this do you mean returning one of the many error codes in an >> HTTP >> response when the server is overloaded? >> >> I would recommend against that if that's the case. In theory it's >> nice >> to return an error code to clients that could be waiting. In >> practice, >> your queue is already overloaded, so taking more time to send a >> response >> to clients only adds to the problem. In a modern system this isn't >> such >> a big deal, but in Ruby it becomes a mess because of the file id >> limits >> in the select loop. >> >> I'd say, if you add that, make it optional to turn it off and be >> prepared with a FAQ about it in case people have problems. >> >> Have fun. >> >> -- >> Zed A. Shaw >> http://freehackersunion.org/ >> _______________________________________________ >> Mongrel-development mailing list >> Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org >> http://rubyforge.org/mailman/listinfo/mongrel-development >> > > > > -- > Evan Weaver > _______________________________________________ > Mongrel-development mailing list > Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org > http://rubyforge.org/mailman/listinfo/mongrel-development ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Mongrel 2.0 2008-11-18 5:36 ` Zed A. Shaw 2008-11-18 5:49 ` Evan Weaver @ 2008-11-18 14:59 ` Kirk Haines [not found] ` <f4cd26df0811180659n218275a4hf06313ca8f48eed0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 1 sibling, 1 reply; 14+ messages in thread From: Kirk Haines @ 2008-11-18 14:59 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote: > Very cool, nice work. One small comment... > > On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >> Hi Mongrels, >> >> - Error code instead of connection-close, as discussed earlier > > With this do you mean returning one of the many error codes in an HTTP > response when the server is overloaded? > > I would recommend against that if that's the case. In theory it's nice > to return an error code to clients that could be waiting. In practice, > your queue is already overloaded, so taking more time to send a response > to clients only adds to the problem. In a modern system this isn't such > a big deal, but in Ruby it becomes a mess because of the file id limits > in the select loop. In an overload situation, I think that just dropping the connection is an acceptable thing to do, though. The mongrel is overloaded, so it is a correct and beneficial response on the part of the proxy to assume something is wrong with it, and to stop sending traffic to it for a while. The use case for sending a response instead of just dropping the connection is when the HTTP parser throws an exception because of malformed HTTP. Currently that results in an immediate closed connection. The problem there is that upstream proxies can assume that getting the connection cut unexpectedly means that the mongrel itself has a problem. If that proxy responds to this by removing that mongrel from the proxy rotation for a period of time, one misbehaving client, whether intentionally or unintentionally, can DOS a whole cluster. The fix is to just return a canned 400 response before closing. Kirk Haines ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <f4cd26df0811180659n218275a4hf06313ca8f48eed0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Mongrel 2.0 [not found] ` <f4cd26df0811180659n218275a4hf06313ca8f48eed0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2008-11-18 16:22 ` Evan Weaver 0 siblings, 0 replies; 14+ messages in thread From: Evan Weaver @ 2008-11-18 16:22 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw Whether the mongrel is overloaded such that responding further degrades service depends on whether you are blocked on local CPU or on a shared resource. In my experience, shared resource problems are more common. Evan On 11/18/08, Kirk Haines <wyhaines-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote: >> Very cool, nice work. One small comment... >> >> On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >>> Hi Mongrels, >>> >>> - Error code instead of connection-close, as discussed earlier >> >> With this do you mean returning one of the many error codes in an HTTP >> response when the server is overloaded? >> >> I would recommend against that if that's the case. In theory it's nice >> to return an error code to clients that could be waiting. In practice, >> your queue is already overloaded, so taking more time to send a response >> to clients only adds to the problem. In a modern system this isn't such >> a big deal, but in Ruby it becomes a mess because of the file id limits >> in the select loop. > > In an overload situation, I think that just dropping the connection is > an acceptable thing to do, though. The mongrel is overloaded, so it > is a correct and beneficial response on the part of the proxy to > assume something is wrong with it, and to stop sending traffic to it > for a while. > > The use case for sending a response instead of just dropping the > connection is when the HTTP parser throws an exception because of > malformed HTTP. > > Currently that results in an immediate closed connection. The problem > there is that upstream proxies can assume that getting the connection > cut unexpectedly means that the mongrel itself has a problem. If that > proxy responds to this by removing that mongrel from the proxy > rotation for a period of time, one misbehaving client, whether > intentionally or unintentionally, can DOS a whole cluster. > > The fix is to just return a canned 400 response before closing. > > > Kirk Haines > _______________________________________________ > Mongrel-development mailing list > Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org > http://rubyforge.org/mailman/listinfo/mongrel-development > -- Evan Weaver ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Mongrel 2.0 [not found] ` <b6f68fc60811171232s46ba20ebh19ff2d499494622d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-17 20:33 ` Evan Weaver 2008-11-18 5:36 ` Zed A. Shaw @ 2008-11-20 3:09 ` Luis Lavena [not found] ` <71166b3b0811191909n6ad79b3cse89be4b9c50b8283-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-12-06 0:48 ` Eric Wong 3 siblings, 1 reply; 14+ messages in thread From: Luis Lavena @ 2008-11-20 3:09 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw On Mon, Nov 17, 2008 at 6:32 PM, Evan Weaver <evan-72XWLPH10WVXUHR/Jj/Uug@public.gmane.org> wrote: > Hi Mongrels, > > I'm working on trunk and would like to change the following things and > release it as a 2.0rc. > > - Timestamped logging > - 1.9.1rc compatibility > - Early PID drop > - Error code instead of connection-close, as discussed earlier > - Option to fork and run from a shared socket on Linux instead of queueing Can you give more details on this? > - Move to a Rack handler interface, and include backwards-compatible > versions of the current ones How this will overlap / affect / interfere Rack and it's own handler for mongrel? > - Eliminate gem_plugins > - Other random bugfixes from off the trac and github > I'll really liek to have mongrel repository moved to git prior the release, I lost track of all the branches and what is current the past months... > I'm unsure of what to do about mongrel_cluster. Do people still use > that? Only for the --clean option? It would be nice if it could go > away. > > At a later date, I would like to include optional ESI parsing to help > people's dev environments. > > Please fuss at me if these are bad. > Most of thos looks good, but hearing more the details of some points details will help me a bit. For the record, I'm working on some rake helpers to ease the building of all the gems and also cross compilation, with the goal that noone needs me or Windows to be able to release gems for the platform. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <71166b3b0811191909n6ad79b3cse89be4b9c50b8283-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Mongrel 2.0 [not found] ` <71166b3b0811191909n6ad79b3cse89be4b9c50b8283-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2008-11-20 4:39 ` Kirk Haines [not found] ` <f4cd26df0811192039r7b96da46j5fde78edcc80cf91-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 14+ messages in thread From: Kirk Haines @ 2008-11-20 4:39 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw >> - Option to fork and run from a shared socket on Linux instead of queueing > > Can you give more details on this? On Linux (and some other *nixes), there's a funky little thing that happens when a process that is bound to a socket is forked. All of the forked processes are also bound to the socket, and the kernel will distribute connections between them. It's a low cost way to load balance between workers on a machine that is running an OS which will support it. Kirk Haines ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <f4cd26df0811192039r7b96da46j5fde78edcc80cf91-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Mongrel 2.0 [not found] ` <f4cd26df0811192039r7b96da46j5fde78edcc80cf91-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2008-11-20 5:54 ` Tony Arcieri [not found] ` <c7e6b2b00811192154i1c2fb8f9g4cf70045c277e2a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 14+ messages in thread From: Tony Arcieri @ 2008-11-20 5:54 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw [-- Attachment #1.1: Type: text/plain, Size: 606 bytes --] On Wed, Nov 19, 2008 at 9:39 PM, Kirk Haines <wyhaines-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On Linux (and some other *nixes), there's a funky little thing that > happens when a process that is bound to a socket is forked. > > All of the forked processes are also bound to the socket, and the > kernel will distribute connections between them. It's a low cost way > to load balance between workers on a machine that is running an OS > which will support it. > Prefork servers should be fairly portable. Any reason why you aren't trying this on other platforms? -- Tony Arcieri medioh.com [-- Attachment #1.2: Type: text/html, Size: 979 bytes --] [-- Attachment #2: Type: text/plain, Size: 199 bytes --] _______________________________________________ Mongrel-development mailing list Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org http://rubyforge.org/mailman/listinfo/mongrel-development ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <c7e6b2b00811192154i1c2fb8f9g4cf70045c277e2a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Mongrel 2.0 [not found] ` <c7e6b2b00811192154i1c2fb8f9g4cf70045c277e2a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2008-11-21 18:03 ` Evan Weaver 0 siblings, 0 replies; 14+ messages in thread From: Evan Weaver @ 2008-11-21 18:03 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw I was under the impression that it wasn't portable. If it is, that would be great. Evan On Wed, Nov 19, 2008 at 9:54 PM, Tony Arcieri <tony-c1HG4ClrhSvQT0dZR+AlfA@public.gmane.org> wrote: > On Wed, Nov 19, 2008 at 9:39 PM, Kirk Haines <wyhaines-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >> On Linux (and some other *nixes), there's a funky little thing that >> happens when a process that is bound to a socket is forked. >> >> All of the forked processes are also bound to the socket, and the >> kernel will distribute connections between them. It's a low cost way >> to load balance between workers on a machine that is running an OS >> which will support it. > > Prefork servers should be fairly portable. Any reason why you aren't trying > this on other platforms? > > -- > Tony Arcieri > medioh.com > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org > http://rubyforge.org/mailman/listinfo/mongrel-development > > -- Evan Weaver ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Mongrel 2.0 [not found] ` <b6f68fc60811171232s46ba20ebh19ff2d499494622d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> ` (2 preceding siblings ...) 2008-11-20 3:09 ` Luis Lavena @ 2008-12-06 0:48 ` Eric Wong 3 siblings, 0 replies; 14+ messages in thread From: Eric Wong @ 2008-12-06 0:48 UTC (permalink / raw) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw Evan Weaver <evan-72XWLPH10WVXUHR/Jj/Uug@public.gmane.org> wrote: > Hi Mongrels, Hi Evan, > I'm working on trunk and would like to change the following things and > release it as a 2.0rc. Is this still happening in SVN? I haven't seen anything (of course, you may be busy, as I haven't checked this list in nearly a month, either :x) > - 1.9.1rc compatibility Will we be trying different connection/thread models to (possibly) work better with the 1.9 and its use of native threading? Fibers, maybe? or just use async sockets in our code explicitly... -- Eric Wong ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-12-06 0:49 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-11-17 20:32 Mongrel 2.0 Evan Weaver [not found] ` <b6f68fc60811171232s46ba20ebh19ff2d499494622d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-17 20:33 ` Evan Weaver [not found] ` <b6f68fc60811171233y7f103da0od5e875007f153f15-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-17 20:47 ` Ezra Zygmuntowicz [not found] ` <B99E038D-E0E5-43D1-8DCA-08957639F2CF-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2008-11-17 22:55 ` Filipe Lautert 2008-11-18 5:36 ` Zed A. Shaw 2008-11-18 5:49 ` Evan Weaver [not found] ` <b6f68fc60811172149i5d0c8261ldba15c02212d6a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-20 2:31 ` Wayne Seguin 2008-11-18 14:59 ` Kirk Haines [not found] ` <f4cd26df0811180659n218275a4hf06313ca8f48eed0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-18 16:22 ` Evan Weaver 2008-11-20 3:09 ` Luis Lavena [not found] ` <71166b3b0811191909n6ad79b3cse89be4b9c50b8283-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-20 4:39 ` Kirk Haines [not found] ` <f4cd26df0811192039r7b96da46j5fde78edcc80cf91-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-20 5:54 ` Tony Arcieri [not found] ` <c7e6b2b00811192154i1c2fb8f9g4cf70045c277e2a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2008-11-21 18:03 ` Evan Weaver 2008-12-06 0:48 ` Eric Wong
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).