From zedshaw at zedshaw.com Sat Apr 1 04:35:03 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sat, 01 Apr 2006 04:35:03 -0500 Subject: [Mongrel] 0.3.12.1 Quick Bug Fix Pre-Release Message-ID: I've got the 0.3.12.1 pre-release up for people to check out. It has just a few minor changes: * You can now finally specify your own Configurator config and add any handlers or plugins you want. You basically just pass in the -S option and give it a .rb file to load. Mongrel will load this file after it's done configuring the stuff it needs. This means you can use any of the function calls in Configurator or RailsConfigurator to augment the default Mongrel setup. This lets you register your own handlers, load different plugins, etc. * It populates the REMOTE_ADDR header now but more intelligently. If HTTP_X_FORWARDED_FOR is available, then it uses that, otherwise it gets the remote IP from the socket. This means that when Mongrel is behind a proxy server it will use the connecting client's IP rather than the proxy server's, but when you run it directly it will report the actual remote client. * It now logs the requests to the STDERR console when you flip on debugging with -B. * Fixes for an extra log message when loading MIME types. * Cleaned up the extraneous logging in the tests. Please do the usual pre-release grabbing and testing and then I'll release tomorrow afternoon. gem install mongrel --source=http://mongrel.rubyforge.org/releases/ Zed From zedshaw at zedshaw.com Tue Apr 4 02:12:45 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Tue, 04 Apr 2006 02:12:45 -0400 Subject: [Mongrel] Mongrel Web Server 0.3.12.1 -- Iron Mongrel Message-ID: Hello All Mongrel Users, For the unintiated, Mongrel is a web server that runs Ruby web applications really fast. Read http://mongrel.rubyforge.org/ to get find out more about it. This is the Iron Mongrel release. It is the result of trying to trash Mongrel until it can't move and then fixing anything that comes up. The work was done on EastMedia's and VeriSign's upcoming project in order to make sure it can handle heavy loads and potentially malformed requests. The project is a security and identity project so having a web server that is able to block bad requests is very important. The testing methods used were (are): 1. Unit testing what I can. Mongrel is a server so many tests have to be done "live". 2. Thrashing Mongrel's HTTP parser internally with random or near-random data (called fuzzing). 3. Using "Peach Fuzz":http://peachfuzz.sourceforge.net/ to thrash several live apps with randomness. 4. Running several extensive little scripts to explore the edges of death for Mongrel. 5. Heavy code audits covering as much code as possible to find any possible loose ends. The end result is a lot of little fixes which make Mongrel more robust against badly behaving clients and possibly against many potential security risks in the future. In general Mongrel 0.3.12.1 behaves more consistently compared to past releases when given random data or maliciously formatted data. The main changes are related to how IO is processed and how the HTTP parser rejects "bad" input. What the parser now blocks is: * Any header over 112k. * Any query string over 10k. * Any header field value over 80k. * Any header field name over 256 bytes. * Any request URI (the file part, not the whole thing) greater than 512 bytes. As soon as these conditions are detected the client is disconnected immediately and a log message is printed out listing the IP address, the exact cause, and the data that caused it. I'll remove the data dump later, but I want people to shoot me valid requests that cause parser errors. That's not all though. I've started a "security":security.html page where I'll publish the results of security threats, tests, and improvements as well as any advice for folks. This release also features a few little features here and there: * Initial support for a "config script". I'll be documenting this more, but it basically lets you use the Mongrel::RailsConfigurator to augment your application's config via a small script. Just pass "-S config/mongrel.rb" and put any Mongrel::RailsConfigurator statements that are reasonable. * Mongrel will report the correct REMOTE_ADDR variable, but it does a little trick where if there is an X-FORWARDED-FOR header then it sets REMOTE_ADDR to that. * Fixes for little bugs like double log messages, but not a lot of changes to the overall core. Go ahead and install the usual way: gem install mongrel *or* gem upgrade Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ P.S. The snazzy Iron Mongrel logo is courtesy court3nay from http://caboo.se/ From zedshaw at zedshaw.com Tue Apr 4 13:09:46 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Tue, 04 Apr 2006 13:09:46 -0400 Subject: [Mongrel] [ANN] Mongrel Web Server 0.3.12.2 -- Iron Mongrel (Parser Fix) Message-ID: Hello Everyone, This is an ultra quick announce for a bug fix release to Mongrel. It corrects a small change in the HTTP parser that causes an error when people use multi-part forms in a certain way. The fix is literally 4 characters changed in the parser specification. Everyone should update to this release and let me know if their forms act really weird. I've tested various upload types but some folks seem to be doing original upload encodings. This parser should catch them consistently. You can upgrade using: gem upgrade Or using: gem install mongrel I just posted the gems so it might take a bit to get the fix. Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ From steve at waits.net Tue Apr 4 17:01:09 2006 From: steve at waits.net (Stephen Waits) Date: Tue, 04 Apr 2006 14:01:09 -0700 Subject: [Mongrel] More newbie questions.. Calling out to CGI, Reusing Responses, Multi-thread.. Message-ID: <4432DE95.7030002@waits.net> What I'm building is essentially a filter. On certain URIs, Mongrel will handle the request completely. On other URIs, I'd like to pass that responsibility off to an external CGI process (be it Rails's dispatch.cgi, or otherwise). How do I go about that? Second, I'm finding that in several of my handlers I'd like to reuse a response. However, I couldn't instance a response because it requires a socket. Therefore, I assume it's not meant to work this way. Possible? Finally, am I right in thinking that you can run a multi-threaded server, albeit with Ruby's cruddy threads, by doing something like this: h = Mongrel::HttpServer.new('0.0.0.0', '3000') [h.run, h.run, h.run].each { |t| t.join } Thanks, Steve From zedshaw at zedshaw.com Wed Apr 5 02:54:12 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 05 Apr 2006 02:54:12 -0400 Subject: [Mongrel] More newbie questions.. Calling out to CGI, Reusing Responses, Multi-thread.. In-Reply-To: <4432DE95.7030002@waits.net> Message-ID: Responses below... On 4/4/06 5:01 PM, "Stephen Waits" wrote: > What I'm building is essentially a filter. On certain URIs, Mongrel > will handle the request completely. On other URIs, I'd like to pass > that responsibility off to an external CGI process (be it Rails's > dispatch.cgi, or otherwise). How do I go about that? > Pretty simple. I went over the config/mongrel.rb file on IRC but I'll explain it again real quick for people reading the list. Mongrel uses the Configurator to simplify wiring up Mongrel and handlers: http://mongrel.rubyforge.org/rdoc/classes/Mongrel/Configurator.html There's also the Mongrel::Rails::RailsConfigurator which is a subclass and adds a few little extras. All you gotta do is peak into the mongrel_rails script and see how we use the configurator to hook up rails. It's very readable and works great. In your case, you'd basically have your own script load the HttpHandlers you need and then use a configurator to create listeners with handlers attached to them. The other option is to do it all by hand rather than use the Configurator. If you're looking at doing it this way than at least glance at the Configurator's code so you can see kind of the standard ways all the stuff is wired together. Finally there's a way to make handlers act as GemPlugins so they're easier to load and distribute, but I think you aren't interested in that. If you are then take a look at lib/mongrel/debug.rb to see all the filtering handlers there. For your particular needs you'd just write a HttpHandler that takes a look at the request.params["PATH_INFO"] and if it matches the CGI's path then you'll start the CGI. The nice thing is that I've matched the CGI 1.2 specification as closely as possible so the contents of request.params should be directly applicable to your CGI input. > Second, I'm finding that in several of my handlers I'd like to reuse a > response. However, I couldn't instance a response because it requires a > socket. Therefore, I assume it's not meant to work this way. Possible? > The handlers can be registered to the same URI in order and they'll be run in that order. Take a look at the options to Configurator.uri or HttpServer.register in 0.3.12.2 to see the option to put a handler in front rather than at the end. Mongrel basically runs each handler in order until either all the handlers have ran or one of the handlers "finalizes" the response object. This lets handlers short-circuit the request processing (good for authentication). Each handler then just gets the same request/response objects in order so they can modify them as needed. Handlers can *even* reset the HttpResponse objects, access the headers, status, and bodies and modify them as needed. Now, when you say "reuse" the response, if you mean keep it around for a future request then you'll have problems. The handler chain is particularly tuned so that when the request is processed the response object is basically dead. You could keep it around, but the socket and writing anything to it would not work. It'd basically be read-only. But since you can access all the contents of the response object you could make a special dup method to do what you want. > Finally, am I right in thinking that you can run a multi-threaded > server, albeit with Ruby's cruddy threads, by doing something like this: > > h = Mongrel::HttpServer.new('0.0.0.0', '3000') > [h.run, h.run, h.run].each { |t| t.join } > Nah, that's not necessary. Mongrel is already heavily threaded. You just do one run and it'll spawn off as many threads as it can to handle any requests it gets. As a matter of fact, I'm curious why you thought it *wasn't* running with threads since that's a very important thing to know. Did you read something? In the Rails stuff Mongrel locks Rails prior to running the Rails Dispatcher, but otherwise the rest of Mongrel is all threads all the time. Was that it? Now, if you wanted to live on the very edge and you're on Unix you can try the fork trick to get real mulit-processing. Fork trick is basically where you create the HttpServer, get the socket, and then right after you've established this listening socket you use fork to create multiple listening processes off one socket. How it works is when the OS comes in to get something to handle a client request, it has to pick a process. There's usually some locking and juggling, but the OS will typically pick the first process that can accept the client. Since many processes listen to this one socket you get the best of both worlds: fast in process threads through Ruby and mutli-processing from the OS. Now, before you go running into utopia shooting your leg off there's some warnings: 1) Don't start 100 processes thinking this will make things faster. You're using an N:M thread model so you only need a few processes per CPU to get the best throughput. Usually I do about 4-8 per CPU. 2) It's not that reliable with Ruby. The fork seems to mess with a lot of the Ruby internals making the locking you'd normally get from a nice C program not work the same. 3) You can't restart these processes easily without also writing a bunch of monitoring and health check code. As you go down this rabbit hole you'll start to realize that you're just reinventing all the machinery that a good proxy server, mongrels on each port, and your OS's normal process management already does. Otherwise, give it a shot and see what you get. If you can iron out the stability problems then I'll consider adding it as an option to HttpServer to simplify things. Zed From zedshaw at zedshaw.com Thu Apr 6 09:16:04 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 06 Apr 2006 09:16:04 -0400 Subject: [Mongrel] Mongrel Web Server 0.3.12.3 -- Thread Tracking and Debugging Message-ID: Hello Everyone, Mongrel is getting closer and closer to being a rock solid release. My goal is to release 0.4 as "production ready" by Canada on Rails. Please report any problems or suggestions you have. There won't be any major features or improvements just fixes and code reviews to repair any found bugs or security concerns. People interested in Mongrel should look at http://mongrel.rubyforge.org/ and remember, you can report bugs by clicking on the two yellow beetles. You don't have to join the mailing list as I actively check that bug posting system. You can get Mongrel using: gem install mongrel CONTENT_TYPE FIX If you had garbage file uploads than this release is for you. This release has a small fix for a big problem where people uploading files or using multipart forms would not receive the CONTENT_TYPE and get garbage in their request parameters. Turned out to be a four character fix. I hate that. THREAD DEBUGGING This release also adds a few things to help people debug their use of threads within their Ruby on Rails applications. When you run mongrel_rails with the -B (debugging) option Mongrel will report all active threads between each request to log/mongrel_debug/thread.log. If you see reports of Mongrel being overloaded, threads getting killed, or having to wait for Mongrel to shutdown then turn on debugging (-B) and look in this log. You most likely are doing something that keeps the thread from exiting. Mongrel also deals with dead threads much better. First the graceful shutdown will wait 10 seconds for a request to finish before aborting it during the shutdown process. Second it will find processing threads which have taken longer than 60+timeout seconds and kill them. Finally, you can put a value into your own Thread.current and when you use the thread.log you can figure out which controllers and actions are creating the bad threads. For example, lets say you see a thread leak. Many times this is caused by trying to make a connection to a remote resource that isn't there, but you're not sure. What you do is put this into the suspected controller's action: Thread.current[:bad_controller_action] = true Or some of other tag to differentiate it with the other threads. Then run Mongrel with -B and if you see this in the KEYS list then you know that this is the controller. MYSQL DROPPED CONNECTIONS? ANYONE? Finally, there seems to be a bug in Rails where it is constantly dropping the connection to MySQL. I've found this error on nearly everything and it's worse when you run WEBrick. It seems to get a little better when you set *ActionController::Base.allow_concurrency* in your config/environments the problem is lessened especially if you run Mongrel, which I don't understand at all. I'm still trying to determine the cause of this, but if you see this problem please report it to me with what system you are running and how often you see it. **Remember, this is a Rails problem not a Mongrel problem since I see it with WEBrick, FastCGI, SCGI, and on Win32, FreeBSD, OSX, and Linux.** Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ From lists at kikobu.com Thu Apr 6 14:47:03 2006 From: lists at kikobu.com (Morten) Date: Thu, 06 Apr 2006 20:47:03 +0200 Subject: [Mongrel] Mongrel Web Server 0.3.12.3 -- Thread Tracking and Debugging In-Reply-To: References: Message-ID: <44356227.6070205@kikobu.com> > > MYSQL DROPPED CONNECTIONS? ANYONE? > Aye.. I had that with SCGI running a vanilla Typo 2.6.0. It seemed to happen over night, and my guess was an 8 hour time out or similar from MySQL. I didn't dig for the root cause, I set up a cron job to call my app every 10 minute and it hasn't happened since. I was going to do a similar setup with Mongrel, but when I try to install it on the server I get: ... 28. mongrel 0.2.1 (ruby) 29. mongrel 0.2.0 (ruby) 30. Cancel installation > 1 Install required dependency daemons? [Yn] Y ERROR: While executing gem ... (ArgumentError) parse error on line 0, col 31: `!ruby/object:Gem::Specification ' Anyone know what this may be? Thanks. Morten From jeff at casimircreative.com Thu Apr 6 15:25:42 2006 From: jeff at casimircreative.com (Jeff Casimir) Date: Thu, 06 Apr 2006 15:25:42 -0400 Subject: [Mongrel] Mongrel Web Server 0.3.12.3 -- Thread Tracking and Debugging In-Reply-To: <44356227.6070205@kikobu.com> References: <44356227.6070205@kikobu.com> Message-ID: <44356B36.8010409@casimircreative.com> Morten, I got the same error. It took me awhile to figure out that I was running Ruby 1.8.2 and needed to upgrade to 1.8.4. There is a "Release Candidate 1" on RubyForge that works great (assuming you're also on Windows). -Jeff Morten wrote: >>MYSQL DROPPED CONNECTIONS? ANYONE? >> >> >> > >Aye.. I had that with SCGI running a vanilla Typo 2.6.0. It seemed to >happen over night, and my guess was an 8 hour time out or similar from >MySQL. I didn't dig for the root cause, I set up a cron job to call my >app every 10 minute and it hasn't happened since. > >I was going to do a similar setup with Mongrel, but when I try to >install it on the server I get: > >... > 28. mongrel 0.2.1 (ruby) > 29. mongrel 0.2.0 (ruby) > 30. Cancel installation > > 1 >Install required dependency daemons? [Yn] Y >ERROR: While executing gem ... (ArgumentError) > parse error on line 0, col 31: `!ruby/object:Gem::Specification ' > >Anyone know what this may be? > >Thanks. > >Morten > > > > > >_______________________________________________ >Mongrel-users mailing list >Mongrel-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/mongrel-users > > From lists at kikobu.com Thu Apr 6 15:59:19 2006 From: lists at kikobu.com (Morten) Date: Thu, 06 Apr 2006 21:59:19 +0200 Subject: [Mongrel] Mongrel Web Server 0.3.12.3 -- Thread Tracking and Debugging In-Reply-To: <44356B36.8010409@casimircreative.com> References: <44356227.6070205@kikobu.com> <44356B36.8010409@casimircreative.com> Message-ID: <44357317.3040705@kikobu.com> Jeff Casimir wrote: > Morten, > > I got the same error. It took me awhile to figure out that I was > running Ruby 1.8.2 and needed to upgrade to 1.8.4. There is a "Release > Candidate 1" on RubyForge that works great (assuming you're also on > Windows). I'm on Linux, but it was indeed the Ruby version. Upgraded and works nicely! Thanks Jeff :-) From doug at beaver.net Fri Apr 7 15:30:03 2006 From: doug at beaver.net (Doug Beaver) Date: Fri, 7 Apr 2006 15:30:03 -0400 Subject: [Mongrel] HTTP 1.1 parser and non-standard request methods Message-ID: <20060407193003.GB95600@beaver.net> hi, i was thinking of creating a WebDAV plugin for mongrel, but ran into an issue... the http parser hardcodes which request methods it considers valid, so it blocks non-standard request methods like MKCOL, PROPFIND, etc. i'm not familiar with the type of grammar being used for the parser, but is it possible to defer the request method validation to a later point, possibly inside the HttpHandler#process callback? thanks, doug -- "Contrary to what most people say, the most dangerous animal in the world is not the lion or the tiger or even the elephant. It's a shark riding on an elephant's back, just trampling and eating everything they see." -- Jack Handey From zedshaw at zedshaw.com Fri Apr 7 15:42:07 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 07 Apr 2006 15:42:07 -0400 Subject: [Mongrel] HTTP 1.1 parser and non-standard request methods In-Reply-To: <20060407193003.GB95600@beaver.net> Message-ID: Hey Doug, Yeah, you're probably the 10th person asking for that to be relaxed so I'm going to relax it in the next release. But, I have to resolve how the ruby frameworks will handle this. I'm not sure what they'll do if handed an kind of request type. Zed On 4/7/06 3:30 PM, "Doug Beaver" wrote: > hi, > > i was thinking of creating a WebDAV plugin for mongrel, but ran into an > issue... the http parser hardcodes which request methods it considers > valid, so it blocks non-standard request methods like MKCOL, PROPFIND, > etc. i'm not familiar with the type of grammar being used for the > parser, but is it possible to defer the request method validation to a > later point, possibly inside the HttpHandler#process callback? > > thanks, > > doug From evilgeenius at gmail.com Fri Apr 7 15:50:00 2006 From: evilgeenius at gmail.com (Chris Richards) Date: Fri, 7 Apr 2006 20:50:00 +0100 Subject: [Mongrel] Is mongrel stable enough to be used in a production environment? Message-ID: Is mongrel stable enough to be used in a production environment? Is it stable? If so, which version is recommended? Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060407/8d3ad7b4/attachment.htm From schoenm at earthlink.net Sat Apr 8 00:53:49 2006 From: schoenm at earthlink.net (Michael Schoen) Date: Fri, 07 Apr 2006 21:53:49 -0700 Subject: [Mongrel] Mongrel Web Server 0.3.12.1 -- Iron Mongrel In-Reply-To: References: Message-ID: <443741DD.2020505@earthlink.net> Zed Shaw wrote: > This keeps Mongrel light and lets people extend it for their own needs. > There's already people using GemPlugins to implement management commands > through Capistrano, security enhancements, and monitoring for Mongrel. Do you know if those folks would mind sharing the Capistrano and monitoring plugins? Also, are you planning on something like scgi_cluster, to make it easier to configure and manage clusters of Mongrels (eg, proxied behind lighttpd)? From zedshaw at zedshaw.com Sat Apr 8 14:09:11 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sat, 08 Apr 2006 14:09:11 -0400 Subject: [Mongrel] [ANN] Mongrel 0.3.12.4 Pre-Release -- Please Test (Not Win32) Message-ID: Morning Folks, I have a pre-release of Mongrel 0.3.12.4 up on the releases site that I'd appreciate everyone testing out. This release fixes the following: * Corrects the date format returned so that months are three chars only. * Fixes a problem where DirHandler wasn't returning Last-Modified and Etag headers for unknown MIME types. * Implements a default mime type for anything it doesn't know about, and lets you set it via an attribute in DirHandler if you want different. * Cleans up the file serving code in DirHandler a bit. * Relaxes the parser to that it will accept any request methods as long as they are upper case, digits, safe chars ($ - _ .) and with length from 1-20 characters. Anything outside this restriction is still rejected with a close. You can get this release from the pre-releases spot with: gem install mongrel --source=http://mongrel.rubyforge.org/releases/ And there isn't a win32 gem yet since I have to test on that platform and want to make some additional fixes for them. Thanks and please report your to the rubyforge tracker: http://rubyforge.org/tracker/?atid=5145&group_id=1306&func=browse I actually use it. Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ From zedshaw at zedshaw.com Sat Apr 8 14:40:23 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sat, 08 Apr 2006 14:40:23 -0400 Subject: [Mongrel] [ANN] Mongrel 0.3.12.4 Pre-Release -- Please Test (Not Win32) In-Reply-To: Message-ID: On 4/8/06 2:09 PM, "Zed Shaw" wrote: > Morning Folks, > > I have a pre-release of Mongrel 0.3.12.4 up on the releases site that I'd > appreciate everyone testing out. This release fixes the following: Whoops, found a bug. Update again if you just tried it. Zed From zedshaw at zedshaw.com Sat Apr 8 15:28:21 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sat, 08 Apr 2006 15:28:21 -0400 Subject: [Mongrel] Is mongrel stable enough to be used in a production environment? In-Reply-To: Message-ID: I?m currently taking the 0.3.12.x release and making it stable and robust in the face of malformed protocol requests or giant ?moby? requests. There is a pre-release available (0.3.12.4) from: gem install mongrel ?source=http://mongrel.rubyforge.org/releases/ Which you might want to try in order to get a jump on it?s stability. This release mostly just fixes the Date formatting to be RFC compliant. I?m telling people that the 0.3.13 release will be the ?stable for pre-production release?. This means that you can start putting your pre-production and staging systems on it for testing and evaluation purposes. At Canada on Rails I plan on getting together with as many people as possible and trying to get their applications to run Mongrel as my main testing process. After Canada on Rails I?m planning the 0.4 release and will start telling people it?s production ready. Now, before people go crazy and start running their rails applications on Mongrel expecting google size loads, there?s quite a few things that ?Mongrel in production? is really missing: * A monitoring best practice. I?m looking at monit for this and should have a doc for people soon. * A multi-machine cached cluster best practice. There?s one using lighttpd that works, but there?s some bugs in lighttpd?s mod_proxy that makes it not so great. I should have a new version of the document which clears all this up. * Management mechanisms. Monit should take care of things like stray mongrels (pun!) and bouncing badly behaving servers. It would be nice to give people a small handler that lets them hit a mongrel server on a separate host to see what it?s doing and manage it a bit. Hope that answers your question. Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ On 4/7/06 3:50 PM, "Chris Richards" wrote: > Is mongrel stable enough to be used in a production environment? Is it > stable? > If so, which version is recommended? > Thanks, > > Chris > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060408/1bc375cd/attachment.htm From kevwil at gmail.com Sat Apr 8 22:17:52 2006 From: kevwil at gmail.com (Kevin Williams) Date: Sat, 8 Apr 2006 20:17:52 -0600 Subject: [Mongrel] Is mongrel stable enough to be used in a production environment? In-Reply-To: References: Message-ID: <683a886f0604081917m1a8e4b94wc7b3fee15af778b7@mail.gmail.com> I *really* don't mean to be a jerk, but why not call the "production"release 1.0? I'm sure you have your reasons, I guess, but I think ifit's public and production-worthy, it should be at least 1.0. Just athought - getting set in my ways as I get old probably. ;) Cheers, Kevin On 4/8/06, Zed Shaw wrote:> I'm currently taking the 0.3.12.x release and making it stable and robust> in the face of malformed protocol requests or giant "moby" requests. There> is a pre-release available (0.3.12.4) from:>> gem install mongrel> ?source=http://mongrel.rubyforge.org/releases/>> Which you might want to try in order to get a jump on it's stability. This> release mostly just fixes the Date formatting to be RFC compliant.>> I'm telling people that the 0.3.13 release will be the "stable for> pre-production release". This means that you can start putting your> pre-production and staging systems on it for testing and evaluation> purposes. At Canada on Rails I plan on getting together with as many people> as possible and trying to get their applications to run Mongrel as my main> testing process.>> After Canada on Rails I'm planning the 0.4 release and will start telling> people it's production ready.>> Now, before people go crazy and start running their rails applications on> Mongrel expecting google size loads, there's quite a few things that> "Mongrel in production" is really missing:>> * A monitoring best practice. I'm looking at monit for this and should> have a doc for people soon.> * A multi-machine cached cluster best practice. There's one using> lighttpd that works, but there's some bugs in lighttpd's mod_proxy that> makes it not so great. I should have a new version of the document which> clears all this up.> * Management mechanisms. Monit should take care of things like stray> mongrels (pun!) and bouncing badly behaving servers. It would be nice to> give people a small handler that lets them hit a mongrel server on a> separate host to see what it's doing and manage it a bit.>> Hope that answers your question.>> Zed A. Shaw> http://www.zedshaw.com/> http://mongrel.rubyforge.org/>>>> On 4/7/06 3:50 PM, "Chris Richards" wrote:>>>> Is mongrel stable enough to be used in a production environment? Is it> stable?> If so, which version is recommended?> Thanks,>> Chris>> ________________________________> _______________________________________________> Mongrel-users mailing list> Mongrel-users at rubyforge.org> http://rubyforge.org/mailman/listinfo/mongrel-users>>> _______________________________________________> Mongrel-users mailing list> Mongrel-users at rubyforge.org> http://rubyforge.org/mailman/listinfo/mongrel-users>> --Cheers, Kevin "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net From amiroff at gmail.com Sun Apr 9 03:09:47 2006 From: amiroff at gmail.com (Metin Amiroff) Date: Sun, 9 Apr 2006 10:09:47 +0300 Subject: [Mongrel] Is mongrel stable enough to be used in a production environment? In-Reply-To: References: Message-ID: <9328906b0604090009w53fe0a3bu57b13d743d9ef3b4@mail.gmail.com> On 4/8/06, Zed Shaw wrote: > At Canada on Rails I plan on getting together with as many people> as possible and trying to get their applications to run Mongrel as my main> testing process.>> After Canada on Rails I'm planning the 0.4 release and will start telling> people it's production ready. This is the kind of attitude, passion and professionalism I love somuch in Rails community; a big "THANK YOU" guys! Cheers,Metin --Pace Peace Paix Paz Frieden Pax Pok?j Fri?ur Fred B?keHasiti Lap? Hetep Malu M?? Wolakota Santiphap Irini PeochShanti Vrede Bar?? R?j M?r Taika Rongo S?lh Py'guapy From zedshaw at zedshaw.com Sun Apr 9 03:38:21 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 09 Apr 2006 03:38:21 -0400 Subject: [Mongrel] Is mongrel stable enough to be used in a production environment? In-Reply-To: <683a886f0604081917m1a8e4b94wc7b3fee15af778b7@mail.gmail.com> Message-ID: On 4/8/06 10:17 PM, "Kevin Williams" wrote: > I *really* don't mean to be a jerk, but why not call the "production"release > 1.0? I'm sure you have your reasons, I guess, but I think ifit's public and > production-worthy, it should be at least 1.0. Just athought - getting set in > my ways as I get old probably. ;) Oh see my plan is to release Mongrel the way Sun Releases Java revisions. The official release working title is: Mongrel 0.4 Enterprise Edition 1.2 I figure if they can get away with three names for the same thing then I can too. Zed From spmikedev at yahoo.com Sun Apr 9 07:27:01 2006 From: spmikedev at yahoo.com (Mike M) Date: Sun, 9 Apr 2006 04:27:01 -0700 (PDT) Subject: [Mongrel] Several applications on one box In-Reply-To: Message-ID: <20060409112701.96997.qmail@web50202.mail.yahoo.com> Question: Is it possible to run several applications using a single mongrel instance? Background: I want to set up several low-traffic sites on one server. I now have this configuration: Apache virtual-host for domain1 -> proxy to mongrel instance 1 on port 3000 Apache virtual-host for domain2 -> proxy to mongrel instance 2 on port 3001 etc etc. Ideally, I'd like a pool of say 4 mongrel instances to serve all the applications. Thanks, Mike __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kevwil at gmail.com Sun Apr 9 11:41:55 2006 From: kevwil at gmail.com (Kevin Williams) Date: Sun, 9 Apr 2006 09:41:55 -0600 Subject: [Mongrel] Is mongrel stable enough to be used in a production environment? In-Reply-To: References: <683a886f0604081917m1a8e4b94wc7b3fee15af778b7@mail.gmail.com> Message-ID: <683a886f0604090841x3370aa5k7480020c1472f73@mail.gmail.com> I LIKE IT! :) On 4/9/06, Zed Shaw wrote:>>>> On 4/8/06 10:17 PM, "Kevin Williams" wrote:>> > I *really* don't mean to be a jerk, but why not call the "production"release> > 1.0? I'm sure you have your reasons, I guess, but I think ifit's public and> > production-worthy, it should be at least 1.0. Just athought - getting set in> > my ways as I get old probably. ;)>> Oh see my plan is to release Mongrel the way Sun Releases Java revisions.> The official release working title is:>> Mongrel 0.4 Enterprise Edition 1.2>> I figure if they can get away with three names for the same thing then I can> too.>> Zed>>> _______________________________________________> Mongrel-users mailing list> Mongrel-users at rubyforge.org> http://rubyforge.org/mailman/listinfo/mongrel-users> --Cheers, Kevin "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net From zedshaw at zedshaw.com Mon Apr 10 11:37:00 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 10 Apr 2006 11:37:00 -0400 Subject: [Mongrel] [ANN] Mongrel Web Server 0.3.12.4 -- Relaxed Parser, Date Fix Message-ID: Hello Everyone, Just a small announcement for Mongrel 0.3.12.4 which fixes the following things: * Corrects the date format returned so that months are three chars only. * Fixes a problem where DirHandler wasn't returning Last-Modified and Etag headers for unknown MIME types. * Implements a default mime type for anything it doesn't know about, and lets you set it via an attribute in DirHandler if you want different. * Cleans up the file serving code in DirHandler a bit. * Relaxes the parser to that it will accept any request methods as long as they are upper case, digits, safe chars ($ - _ .) and with length from 1-20 characters. Anything outside this restriction is still rejected with a close. It has been tested under the usual platforms (Linux, FreeBSD, OSX, Win32) so people on other platforms should report to me any experiences. You can get information on Mongrel at http://mongrel.rubyforge.org/ and you can download it from the gem repositories as soon as it hits the mirrors. REPORTING BUGS A couple people complained that they hate joining mailing lists to report bugs. I hate that too. That's why there's two yellow bugs on the main page which go to: http://rubyforge.org/tracker/?atid=5145&group_id=1306&func=browse Where you can report bugs and I'll fix them. If you take a look I've already done 11 bugs. WIN32 0.3.12.5 The 0.3.12.5 release will be for cleaning up the differences between POSIX and Win32 systems. The plan is to get rid of mongrel_rails_service and the mongrel_rails_svc command and start using one consistent mongrel_rails command for all platforms. CANDA ON RAILS Finally I'll be at Canada on Rails and I'm looking to meet with people who have problems running Mongrel or who have production applications and are interested in getting Mongrel to run them. E-mail me off-list if you're interested in meeting up with me. THE BIG PRODUCTION RELEASE About a week after Canada on Rails I'll have everyone's feedback incorporated and will do the release that I consider production ready. I'm going to version this release as: Mongrel 0.4 Enterprise Edition 1.2 This is to keep up with the Java trend of tacking the word "Enterprise" onto anything they want to sell and giving it two version numbers: one for developers and one for managers. If you're looking for a set of elevator pitches for Mongrel, then I would suggest these after this release: * "Mongrel powers the Web 2.0 revolution just like Rails." * "Mongrel's enterprise ready, look, says so right in the name." * "Mongrel's version 1.2, Rails is only 1.1.58." * "Sure Mongrel can scale, all you do is strap a salmon to the jello and it scales just fine." -- Makes about as much sense as Java's scalability arguments so why not. Enjoy! Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ From luislavena at gmail.com Mon Apr 10 15:25:33 2006 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 10 Apr 2006 16:25:33 -0300 Subject: [Mongrel] [ANN] Mongrel Web Server 0.3.12.4 -- Relaxed Parser, Date Fix In-Reply-To: References: Message-ID: <71166b3b0604101225s66952dc1m5dec746fba04ecfd@mail.gmail.com> Hello list! I've been out of sight doing some hard and dirty coding on old, 20-years old mainframes for the past weeks :P Anyway, returning to this new and shinny century, check my comments below: On 4/10/06, Zed Shaw wrote: > Hello Everyone, > [...] > WIN32 0.3.12.5 > > The 0.3.12.5 release will be for cleaning up the differences between POSIX > and Win32 systems. The plan is to get rid of mongrel_rails_service and the > mongrel_rails_svc command and start using one consistent mongrel_rails > command for all platforms. > I hope your idea is using GemPlugin to hook in the URI the commands similar to the ones used my mongrel_rails. I was thinking more in just "mongrel" and create some validators that analyze the working directory to check if its rails, nitro/og or camping folder structure or could force to one of them. Also, I want to contribute and participate, any hope? :-) > [...] > THE BIG PRODUCTION RELEASE > > About a week after Canada on Rails I'll have everyone's feedback > incorporated and will do the release that I consider production ready. I'm > going to version this release as: > > Mongrel 0.4 Enterprise Edition 1.2 > > This is to keep up with the Java trend of tacking the word "Enterprise" onto > anything they want to sell and giving it two version numbers: one for > developers and one for managers. > > If you're looking for a set of elevator pitches for Mongrel, then I would > suggest these after this release: > > * "Mongrel powers the Web 2.0 revolution just like Rails." > * "Mongrel's enterprise ready, look, says so right in the name." > * "Mongrel's version 1.2, Rails is only 1.1.58." > * "Sure Mongrel can scale, all you do is strap a salmon to the jello and > it scales just fine." > -- Makes about as much sense as Java's scalability arguments so why > not. > I hope you're joking, right? Remembering 1 version number schema is difficult right now, 2 in the same product name??? Oh, also the "Enterprise" and what about "Professional" part of the name?. If you aren't a guy with big bucks and a big jacuzzi, use the Pro version instead, of couse... Later, Luis PS: That was a bit of sarcasm, hope J2EE guys hanging over here don't take that personal. :-D From why at ruby-lang.org Tue Apr 11 02:11:54 2006 From: why at ruby-lang.org (why the lucky stiff) Date: Tue, 11 Apr 2006 00:11:54 -0600 Subject: [Mongrel] Large file support (up and down) for Mongrel 0.13.3 Message-ID: <443B48AA.8000007@ruby-lang.org> I've just checked in changes to improve handling of massive posts and massive downloads. Generally speaking, Mongrel has been keeping everything in memory. (Unless you're using DirHandler and have the sendfile gem in place.) Now, downloads should be pretty swift even without the sendfile gem. HttpResponse#send_file rips out the file streaming support from DirHandler and encapsulates it. This method doesn't set any of the headers or anything, it just streams the file. The idea here is to allow for support of the X-Sendfile header [1], also supported in lighttpd as of a few days ago. [2] I'm in the mood to keep polishing this, so does anyone lust after mod_uploadprogress support? [3] HttpRequest#initialize also had a TODO about storing large request bodies in a Tempfile. I've fleshed out that code so @body now has either a StringIO object or an open/rewound Tempfile object. It works, you can upload gigs of files just fine. I'm honoring CHUNK_SIZE. There's a threshold in a constant called MAX_BODY. If a file is larger, it'll get canned in a Tempfile. Currently, it's set to the same size as MAX_HEADER. I've added to the test_response.rb appropriately. I've tested the DirHander and CampingHandler. I'm going to test out the Rails handler now. _why [1] http://celebnamer.celebworld.ws/stuff/mod_xsendfile/ [2] http://trac.lighttpd.net/trac/changeset/1097 [3] http://www.lighttpd.net/documentation/upload-progress.html From rsaccon at gmail.com Sun Apr 16 02:21:22 2006 From: rsaccon at gmail.com (Roberto Saccon) Date: Sun, 16 Apr 2006 03:21:22 -0300 Subject: [Mongrel] anyone got lighty working ? Message-ID: Hi all I started to set up a rails stack on debian : debian sarge / XEN 3.0 / Ruby 1.8.4 / Postgresql 8.1.4 / Java 1.5 / Mongrel / Lighttpd Everything went well and worked as expected until I reached lighty. I could not get lighty working at all. I felt like the master of the disaster. I tried the debian backport for lighty 1.4.11, got the ligthy daemon running configured as proxy, but it did not answer any request at all. Any recommendations for a debian package where everything just works out of the box (including the CML-stuff) or a recipe how to get it working ? regards -- Roberto Saccon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060416/b4b5c384/attachment.htm From zedshaw at zedshaw.com Mon Apr 17 16:20:29 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 17 Apr 2006 16:20:29 -0400 Subject: [Mongrel] Several applications on one box In-Reply-To: <20060409112701.96997.qmail@web50202.mail.yahoo.com> Message-ID: Hi Mike, Answers below... On 4/9/06 7:27 AM, "Mike M" wrote: > Question: Is it possible to run several applications using a single mongrel > instance? > Probably not the very best idea really. I believe there's some hacks out there that will make Rails do this, but I've found that mixing Rails with anything--even other rails apps--in the same Ruby process is pure death. My thinking is that if you really wanted to support it then you'd have to somehow have a small Mongrel handler that caught the Host: header and routed to different URLs based on that. If you're going to do this then I'd recommend using mod_rewrite in Apache or Lighttpd. > Background: > I want to set up several low-traffic sites on one server. I now have this > configuration: > > Apache virtual-host for domain1 > -> proxy to mongrel instance 1 on port 3000 > > Apache virtual-host for domain2 > -> proxy to mongrel instance 2 on port 3001 > > etc etc. > > Ideally, I'd like a pool of say 4 mongrel instances to serve all the > applications. > Now, this will work. I know of several people who do this with Apache and Lighttpd. Main thing is to put the Proxy configurations inside the Vhost configs so that when people request domain1 they are proxied back to port 3000, and so on. If your sites are really low traffic then one Mongrel for each site should be good enough. If you want to have many Mongrel servers as backends easily via Apache I recommend you use http://www.inlab.de/balance.html and have it listen on port 3000 and then proxy to as many as you want. In your case you'd run two balance servers: one for port 3001 and another for port 3000. Hope that helps. Zed From spmikedev at yahoo.com Tue Apr 18 15:12:11 2006 From: spmikedev at yahoo.com (Mike M) Date: Tue, 18 Apr 2006 12:12:11 -0700 (PDT) Subject: [Mongrel] Several applications on one box In-Reply-To: Message-ID: <20060418191211.23610.qmail@web50202.mail.yahoo.com> Hi Zed, Thanks for your answers. Actually, in my example, I meant having e.g. 10 virtual domains (=10 applications) that are handled by a pool of say 4 mongrels. But from your first answer I understand that this is not a wise choice. I need a minimum of 1 mongrel per application. Thanks, Mike --- Zed Shaw wrote: > Hi Mike, > > Answers below... > > > On 4/9/06 7:27 AM, "Mike M" wrote: > > > Question: Is it possible to run several applications using a single mongrel > > instance? > > > Probably not the very best idea really. I believe there's some hacks out > there that will make Rails do this, but I've found that mixing Rails with > anything--even other rails apps--in the same Ruby process is pure death. > > My thinking is that if you really wanted to support it then you'd have to > somehow have a small Mongrel handler that caught the Host: header and routed > to different URLs based on that. If you're going to do this then I'd > recommend using mod_rewrite in Apache or Lighttpd. > > > Background: > > I want to set up several low-traffic sites on one server. I now have this > > configuration: > > > > Apache virtual-host for domain1 > > -> proxy to mongrel instance 1 on port 3000 > > > > Apache virtual-host for domain2 > > -> proxy to mongrel instance 2 on port 3001 > > > > etc etc. > > > > Ideally, I'd like a pool of say 4 mongrel instances to serve all the > > applications. > > > > Now, this will work. I know of several people who do this with Apache and > Lighttpd. Main thing is to put the Proxy configurations inside the Vhost > configs so that when people request domain1 they are proxied back to port > 3000, and so on. If your sites are really low traffic then one Mongrel for > each site should be good enough. > > If you want to have many Mongrel servers as backends easily via Apache I > recommend you use http://www.inlab.de/balance.html and have it listen on > port 3000 and then proxy to as many as you want. In your case you'd run two > balance servers: one for port 3001 and another for port 3000. > > Hope that helps. > > Zed > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From zedshaw at zedshaw.com Tue Apr 18 22:30:38 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Tue, 18 Apr 2006 22:30:38 -0400 Subject: [Mongrel] Mongrel 0.3.12.5 -- Pre-Release with File Upload whyness Message-ID: I've got a Mongrel 0.3.12.5 pre-release in the releases directory I'd like people to try out: gem install mongrel --source=http://mongrel.rubyforge.org/releases/ This release incorporates why's changes to allow for uploading files much more efficiently and for streaming out files via a HttpResponse.send_file call. I re-wrote the file upload part what why created to refactor that whole process. It now handles quite a few corner cases related to efficient file uploads: * Writes to a Tempfile if greater than 92k. * Deletes the Tempfile if the user aborts the upload (closed socket). * Detects when not enough was uploaded to match the reported Content-length * Simplifies the upload chunking logic so there's the same socket read loop whether you're uploading a large or small file. The *only* thing that I haven't got quite right is that it seems to leak the Tempfile objects (and thus the files). They stay around after the uploads so I've got to work out whether deleting them is safe or not. Anyway, try the stuff out, especially with something like Park Place and report any bugs you find. Zed From josh at besquared.net Tue Apr 18 23:14:08 2006 From: josh at besquared.net (Josh Ferguson) Date: Tue, 18 Apr 2006 23:14:08 -0400 Subject: [Mongrel] Win32 Gem Dependencies Message-ID: <4445AB00.6000705@besquared.net> Yeah I just noticed that the latest mongrel gem for win32 doesn't have the proper dependency for 'daemons'. This of course causes the require to fail. Any chance at getting this fixed for future gems? :) Thanks Josh Ferguson From dansketcher at gmail.com Tue Apr 18 23:52:25 2006 From: dansketcher at gmail.com (Dan Sketcher) Date: Wed, 19 Apr 2006 13:52:25 +1000 Subject: [Mongrel] Deployment with Capistrano Message-ID: <17ed515b0604182052s6bb42e27i1338ea7386b6186d@mail.gmail.com> Hey all, Has anyone out there got Mongrel deployments working with Capistrano? I've had a crack at setting it up, and I've found that after a deployment (with updated symlinks) that a mongrel restart does not pick up the new deployed site. It seems to me (in my linkted experience) that the HUP that is sent to mongrel does not re-evaluate the ./current symlink that Cap puts in to the appropriate release. If I do a mongrel restart from _outside_ the ./current dir by providing the -e option to mongrel, all is well. The result of all this is that a :restart from Capistrano that just sends a HUP is not effective, but I am not sufficiently familiar as yet with the pathing stuff in Cap to get it going another way. Anyway, if someone has some cleverness that I am missing, it would be greatly appreciated! Cheers, Dan From zedshaw at zedshaw.com Wed Apr 19 00:14:34 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 19 Apr 2006 00:14:34 -0400 Subject: [Mongrel] Win32 Gem Dependencies In-Reply-To: <4445AB00.6000705@besquared.net> Message-ID: Ok, on the bug list. I'm doing a 0.3.12.5 release tomorrow or so and I'll get this fixed up. I have to do lots of testing and fixing up mongrel on win32 anyway. Zed On 4/18/06 11:14 PM, "Josh Ferguson" wrote: > Yeah I just noticed that the latest mongrel gem for win32 doesn't have > the proper dependency for 'daemons'. This of course causes the require > to fail. Any chance at getting this fixed for future gems? :) > > Thanks > Josh Ferguson > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From zedshaw at zedshaw.com Wed Apr 19 00:16:45 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 19 Apr 2006 00:16:45 -0400 Subject: [Mongrel] Deployment with Capistrano In-Reply-To: <17ed515b0604182052s6bb42e27i1338ea7386b6186d@mail.gmail.com> Message-ID: My understanding is summarized on the output Mongrel gives when you start it: ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). ** Rails signals registered. HUP => reload (without restart). On 4/18/06 11:52 PM, "Dan Sketcher" wrote: HUP being a "reload" is done as a soft internal kind of thing, so if you're moving directories around then it won't pick that up. You want USR2. Zed > Hey all, > > Has anyone out there got Mongrel deployments working with Capistrano? > > I've had a crack at setting it up, and I've found that after a > deployment (with updated symlinks) that a mongrel restart does not > pick up the new deployed site. It seems to me (in my linkted > experience) that the HUP that is sent to mongrel does not re-evaluate > the ./current symlink that Cap puts in to the appropriate release. If > I do a mongrel restart from _outside_ the ./current dir by providing > the -e option to mongrel, all is well. The result of all this is that > a :restart from Capistrano that just sends a HUP is not effective, but > I am not sufficiently familiar as yet with the pathing stuff in Cap to > get it going another way. > > Anyway, if someone has some cleverness that I am missing, it would be > greatly appreciated! > > Cheers, > Dan > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From dansketcher at gmail.com Wed Apr 19 00:57:16 2006 From: dansketcher at gmail.com (Dan Sketcher) Date: Wed, 19 Apr 2006 14:57:16 +1000 Subject: [Mongrel] Deployment with Capistrano In-Reply-To: References: <17ed515b0604182052s6bb42e27i1338ea7386b6186d@mail.gmail.com> Message-ID: <17ed515b0604182157i16bdfb10g19fad5a23005b4be@mail.gmail.com> Zed, I was getting some behaviour when using USR2 which seemed to terminate the daemon, but I'll have another look at that and see how I go. Thanks for your help. Dan From josh at besquared.net Wed Apr 19 01:18:45 2006 From: josh at besquared.net (Josh Ferguson) Date: Wed, 19 Apr 2006 01:18:45 -0400 Subject: [Mongrel] Win32 Gem Dependencies In-Reply-To: References: Message-ID: <4445C835.7020603@besquared.net> Since we're on the topic of Win32, I'm having a hell of a time getting mongrel on to run with or without the service. I use Windows XP Pro and Cygwin to do everything on my machine. The problem is that mongrel starts successfully but then when the first request comes in I get the following stack trace: $ mongrel_rails start ** Starting Mongrel in development mode at 0.0.0.0:3000 ** Starting Rails in environment development ... /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/lib/mongrel.rb:539:in `register': undefined method `resolve' for ni l:Mongrel::URIClassifier (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/lib/mongrel.rb:675:in `uri' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/bin/mongrel_rails:82:in `cloaker_' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/lib/mongrel.rb:658:in `listener' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/bin/mongrel_rails:69:in `cloaker_' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/lib/mongrel.rb:616:in `initialize' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/bin/mongrel_rails:61:in `run' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/lib/mongrel/command.rb:163:in `run' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/bin/mongrel_rails:194 from /usr/bin/mongrel_rails:18 I'm not intimate with the code but I looked through it and I couldn't find 'resolve' as a member of URIClassifier or any mixins or run-time extendings that added it. Any help would be appreciated as I'd really love to get this thing running..:) Hating windows Josh Ferguson Zed Shaw wrote: > Ok, on the bug list. I'm doing a 0.3.12.5 release tomorrow or so and I'll > get this fixed up. I have to do lots of testing and fixing up mongrel on > win32 anyway. > > Zed > > > On 4/18/06 11:14 PM, "Josh Ferguson" wrote: > > >> Yeah I just noticed that the latest mongrel gem for win32 doesn't have >> the proper dependency for 'daemons'. This of course causes the require >> to fail. Any chance at getting this fixed for future gems? :) >> >> Thanks >> Josh Ferguson >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From technoweenie at gmail.com Wed Apr 19 01:52:33 2006 From: technoweenie at gmail.com (Rick Olson) Date: Wed, 19 Apr 2006 00:52:33 -0500 Subject: [Mongrel] Mongrel 0.3.12.5 -- Pre-Release with File Upload whyness In-Reply-To: References: Message-ID: <48fe25b0604182252r1227867bwf21bc1d05d86b6bd@mail.gmail.com> On 4/18/06, Zed Shaw wrote: > I've got a Mongrel 0.3.12.5 pre-release in the releases directory I'd like > people to try out: > > gem install mongrel --source=http://mongrel.rubyforge.org/releases/ I just tried out the new mongrel release on my rails app, and the memory didnt go up more than 200k on an 800MB file. That is a massive improvement from the current release on rubyforge. I'm not seeing it in Camping, however. I built a gem from the latest camping from svn, but it still eats up my memory. -- Rick Olson http://techno-weenie.net From dansketcher at gmail.com Wed Apr 19 05:59:42 2006 From: dansketcher at gmail.com (Dan Sketcher) Date: Wed, 19 Apr 2006 19:59:42 +1000 Subject: [Mongrel] Deployment with Capistrano In-Reply-To: <17ed515b0604182157i16bdfb10g19fad5a23005b4be@mail.gmail.com> References: <17ed515b0604182052s6bb42e27i1338ea7386b6186d@mail.gmail.com> <17ed515b0604182157i16bdfb10g19fad5a23005b4be@mail.gmail.com> Message-ID: <17ed515b0604190259g77cfa9d3x6b9449b44147108f@mail.gmail.com> Zed, Under Mongrel 0.3.12.4, on Ruby 1.8.4 1. If I start the daemon under the ./current directory, a USR2 does not pick up the change to the underlying symlink target. 2. If I start the daemon outside the ./current symlink (in the root of the project) passing the -c option, and then send a USR2, the daemon terminates without saying anything to the console or to the log. --- snip --- # mongrel_rails start -d -p 8001 -c current -e production -P log/mongrel-1.pid ** Starting Mongrel in production mode at 0.0.0.0:8001 ** Daemonizing, any open files are closed. Look at log/mongrel-1.pid and log/mongrel.log for info. # ps aux | grep mongrel root 7706 68.5 10.4 22868 19868 ? S 19:55 0:02 /usr/bin/ruby18 /usr/bin/mongrel_rails start -d -p 8001 -c current -e production -P log/mongrel-1.pid root 7708 0.0 0.2 1536 496 pts/1 S+ 19:55 0:00 grep mongrel # kill -USR2 7706 # ps aux | grep mongrel root 7710 0.0 0.2 1540 492 pts/1 R+ 19:55 0:00 grep mongrel --- /snip --- Any ideas? Cheers, Dan From luislavena at gmail.com Wed Apr 19 08:27:52 2006 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 19 Apr 2006 09:27:52 -0300 Subject: [Mongrel] Win32 Gem Dependencies In-Reply-To: <4445C835.7020603@besquared.net> References: <4445C835.7020603@besquared.net> Message-ID: <71166b3b0604190527w1eefa55cuc845343b6305dc00@mail.gmail.com> On 4/19/06, Josh Ferguson wrote: > Since we're on the topic of Win32, I'm having a hell of a time getting > mongrel on to run with or without the service. I use Windows XP Pro and > Cygwin to do everything on my machine. The problem is that mongrel Mmmm, never tried the cygwin env. with mongrel... nor the service part with cygwin, that is what are you doing? From kevwil at gmail.com Wed Apr 19 09:48:39 2006 From: kevwil at gmail.com (Kevin Williams) Date: Wed, 19 Apr 2006 07:48:39 -0600 Subject: [Mongrel] Win32 Gem Dependencies In-Reply-To: <71166b3b0604190527w1eefa55cuc845343b6305dc00@mail.gmail.com> References: <4445C835.7020603@besquared.net> <71166b3b0604190527w1eefa55cuc845343b6305dc00@mail.gmail.com> Message-ID: <683a886f0604190648n54fd5c6ayc64fc2f1f607cc14@mail.gmail.com> Sorry to poke my nose in, but I must say that everything about Railsand Ruby I have tried to do has worked fine without Cygwin. Thisincludes sqlite3, postgresql, mysql, apache2, scgi, fastcgi, lighttpd(limited, but works), and mongrel. You may want to try "goin' native"and see how that works for you. On 4/19/06, Luis Lavena wrote:> On 4/19/06, Josh Ferguson wrote:> > Since we're on the topic of Win32, I'm having a hell of a time getting> > mongrel on to run with or without the service. I use Windows XP Pro and> > Cygwin to do everything on my machine. The problem is that mongrel>> Mmmm, never tried the cygwin env. with mongrel... nor the service part> with cygwin, that is what are you doing?>> _______________________________________________> Mongrel-users mailing list> Mongrel-users at rubyforge.org> http://rubyforge.org/mailman/listinfo/mongrel-users> --Cheers, Kevin "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net From steve at waits.net Wed Apr 19 11:25:15 2006 From: steve at waits.net (Stephen Waits) Date: Wed, 19 Apr 2006 08:25:15 -0700 Subject: [Mongrel] Win32 Gem Dependencies In-Reply-To: <683a886f0604190648n54fd5c6ayc64fc2f1f607cc14@mail.gmail.com> References: <4445C835.7020603@besquared.net> <71166b3b0604190527w1eefa55cuc845343b6305dc00@mail.gmail.com> <683a886f0604190648n54fd5c6ayc64fc2f1f607cc14@mail.gmail.com> Message-ID: <9B4A3087-D45D-4D96-974A-2F9DA1EBAB66@waits.net> On Apr 19, 2006, at 6:48 AM, Kevin Williams wrote: > Sorry to poke my nose in, but I must say that everything about > Railsand Ruby I have tried to do has worked fine without Cygwin. Likewise. Cygwin is always worth avoiding IMO. --Steve From josh at besquared.net Wed Apr 19 11:41:39 2006 From: josh at besquared.net (Josh Ferguson) Date: Wed, 19 Apr 2006 11:41:39 -0400 Subject: [Mongrel] Win32 Gem Dependencies In-Reply-To: <9B4A3087-D45D-4D96-974A-2F9DA1EBAB66@waits.net> References: <4445C835.7020603@besquared.net> <71166b3b0604190527w1eefa55cuc845343b6305dc00@mail.gmail.com> <683a886f0604190648n54fd5c6ayc64fc2f1f607cc14@mail.gmail.com> <9B4A3087-D45D-4D96-974A-2F9DA1EBAB66@waits.net> Message-ID: <44465A33.4030902@besquared.net> I'm definitely sure that ruby, rails, rake, gem, etc would work without cygwin. But then I'd lose everything else that's good about it. Theres is a plethora of nice tools that make my life not suck (ls, grep, ps, ncftp, ssh, etc.) all built in. I spend a lot of my time working with generators, running unit tests, rake deployment tasks, etc. and bash is nice while the normal windows shell sucks. That being said, I didn't install cygwin packages from the installer for any of my ruby/rails or other tools, just normal installs, thus, these errors are not limited to cygwin but to my system as a whole, the stacktrace is the same using my normal cmd prompt which would lead me to believe there is something more amiss than my choice of command shell environments. Josh Ferguson Stephen Waits wrote: > On Apr 19, 2006, at 6:48 AM, Kevin Williams wrote: > > >> Sorry to poke my nose in, but I must say that everything about >> Railsand Ruby I have tried to do has worked fine without Cygwin. >> > > Likewise. > > Cygwin is always worth avoiding IMO. > > --Steve > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From zedshaw at zedshaw.com Wed Apr 19 12:27:38 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 19 Apr 2006 12:27:38 -0400 Subject: [Mongrel] Deployment with Capistrano In-Reply-To: <17ed515b0604190259g77cfa9d3x6b9449b44147108f@mail.gmail.com> Message-ID: Hmmm, let me see what's up. I may have to finally setup Capistrano and get it all working. Bah. Make me do work. :-) Zed On 4/19/06 5:59 AM, "Dan Sketcher" wrote: > Zed, > > Under Mongrel 0.3.12.4, on Ruby 1.8.4 > > 1. If I start the daemon under the ./current directory, a USR2 does > not pick up the change to the underlying symlink target. > > 2. If I start the daemon outside the ./current symlink (in the root of > the project) passing the -c option, and then send a USR2, the daemon > terminates without saying anything to the console or to the log. > > --- snip --- > # mongrel_rails start -d -p 8001 -c current -e production -P log/mongrel-1.pid > ** Starting Mongrel in production mode at 0.0.0.0:8001 > ** Daemonizing, any open files are closed. Look at log/mongrel-1.pid > and log/mongrel.log for info. > # ps aux | grep mongrel > root 7706 68.5 10.4 22868 19868 ? S 19:55 0:02 > /usr/bin/ruby18 /usr/bin/mongrel_rails start -d -p 8001 -c current -e > production -P log/mongrel-1.pid > root 7708 0.0 0.2 1536 496 pts/1 S+ 19:55 0:00 grep mongrel > # kill -USR2 7706 > # ps aux | grep mongrel > root 7710 0.0 0.2 1540 492 pts/1 R+ 19:55 0:00 grep mongrel > --- /snip --- > > Any ideas? > > Cheers, > Dan > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From zedshaw at zedshaw.com Wed Apr 19 12:31:59 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 19 Apr 2006 12:31:59 -0400 Subject: [Mongrel] Win32 Gem Dependencies In-Reply-To: <4445C835.7020603@besquared.net> Message-ID: Uh, I'm not sure how that's possible unless the http11.so extension isn't being installed or compiled. Check in your gem directory and see if it's there. The http11 extension is what provides the resolve method. I vaguely remember that a similar problem happens on Solaris due to a ruby extconf.rb problem and how the install command works. Seems that people just fix it by moving the ext/http11/http11.so file over to lib inside the gem's directory. Zed On 4/19/06 1:18 AM, "Josh Ferguson" wrote: > Since we're on the topic of Win32, I'm having a hell of a time getting > mongrel on to run with or without the service. I use Windows XP Pro and > Cygwin to do everything on my machine. The problem is that mongrel > starts successfully but then when the first request comes in I get the > following stack trace: > > $ mongrel_rails start > ** Starting Mongrel in development mode at 0.0.0.0:3000 > ** Starting Rails in environment development ... > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/lib/mongrel.rb:539:in > `register': undefined method `resolve' for ni From josh at besquared.net Wed Apr 19 13:34:53 2006 From: josh at besquared.net (Josh Ferguson) Date: Wed, 19 Apr 2006 13:34:53 -0400 Subject: [Mongrel] Win32 Gem Dependencies In-Reply-To: References: Message-ID: <444674BD.5020300@besquared.net> It's there but the require fails in irb for some reason. I guess this is a problem I'll have to figure out with my setup.. :) Thanks Josh Ferguson Zed Shaw wrote: > Uh, I'm not sure how that's possible unless the http11.so extension isn't > being installed or compiled. Check in your gem directory and see if it's > there. The http11 extension is what provides the resolve method. > > I vaguely remember that a similar problem happens on Solaris due to a ruby > extconf.rb problem and how the install command works. Seems that people > just fix it by moving the ext/http11/http11.so file over to lib inside the > gem's directory. > > Zed > > > On 4/19/06 1:18 AM, "Josh Ferguson" wrote: > > >> Since we're on the topic of Win32, I'm having a hell of a time getting >> mongrel on to run with or without the service. I use Windows XP Pro and >> Cygwin to do everything on my machine. The problem is that mongrel >> starts successfully but then when the first request comes in I get the >> following stack trace: >> >> $ mongrel_rails start >> ** Starting Mongrel in development mode at 0.0.0.0:3000 >> ** Starting Rails in environment development ... >> /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4-mswin32/lib/mongrel.rb:539:in >> `register': undefined method `resolve' for ni >> > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From why at ruby-lang.org Wed Apr 19 19:28:49 2006 From: why at ruby-lang.org (why the lucky stiff) Date: Wed, 19 Apr 2006 17:28:49 -0600 Subject: [Mongrel] Mongrel 0.3.12.5 -- Pre-Release with File Upload whyness In-Reply-To: References: Message-ID: <4446C7B1.2040204@ruby-lang.org> Zed Shaw wrote: > I've got a Mongrel 0.3.12.5 pre-release in the releases directory I'd like > people to try out: > > gem install mongrel --source=http://mongrel.rubyforge.org/releases/ > > This release incorporates why's changes to allow for uploading files much > more efficiently and for streaming out files via a HttpResponse.send_file > call. > I found a couple bugs and dabbed some ointment on them. Please re-release. I've also got Camping gems out which work better with streaming HTTP. gem install camping --source code.whytheluckystiff.net _why From zedshaw at zedshaw.com Thu Apr 20 00:51:34 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 20 Apr 2006 00:51:34 -0400 Subject: [Mongrel] Mongrel 0.3.12.5 -- Pre-Release with File Upload whyness In-Reply-To: <4446C7B1.2040204@ruby-lang.org> Message-ID: Crap, I forgot to check the last change in and now there's a nasty conflict. On 4/19/06 7:28 PM, "why the lucky stiff" wrote: > Zed Shaw wrote: >> I've got a Mongrel 0.3.12.5 pre-release in the releases directory I'd like >> people to try out: >> >> gem install mongrel --source=http://mongrel.rubyforge.org/releases/ >> >> This release incorporates why's changes to allow for uploading files much >> more efficiently and for streaming out files via a HttpResponse.send_file >> call. >> > I found a couple bugs and dabbed some ointment on them. Please > re-release. I've also got Camping gems out which work better with > streaming HTTP. > > gem install camping --source code.whytheluckystiff.net > > _why > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From zedshaw at zedshaw.com Thu Apr 20 00:57:07 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 20 Apr 2006 00:57:07 -0400 Subject: [Mongrel] Mongrel 0.3.12.5 -- Pre-Release with File Upload whyness In-Reply-To: <4446C7B1.2040204@ruby-lang.org> Message-ID: Alright why, please update your code and take a look. It shouldn't have the bug you reported as it's completely different. Zed On 4/19/06 7:28 PM, "why the lucky stiff" wrote: > Zed Shaw wrote: >> I've got a Mongrel 0.3.12.5 pre-release in the releases directory I'd like >> people to try out: >> >> gem install mongrel --source=http://mongrel.rubyforge.org/releases/ >> >> This release incorporates why's changes to allow for uploading files much >> more efficiently and for streaming out files via a HttpResponse.send_file >> call. >> > I found a couple bugs and dabbed some ointment on them. Please > re-release. I've also got Camping gems out which work better with > streaming HTTP. > > gem install camping --source code.whytheluckystiff.net > > _why > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From why at ruby-lang.org Thu Apr 20 11:40:12 2006 From: why at ruby-lang.org (why the lucky stiff) Date: Thu, 20 Apr 2006 09:40:12 -0600 Subject: [Mongrel] Mongrel 0.3.12.5 -- Pre-Release with File Upload whyness In-Reply-To: References: Message-ID: <4447AB5C.9070000@ruby-lang.org> Zed Shaw wrote: > Alright why, please update your code and take a look. It shouldn't have the > bug you reported as it's completely different. > Perfeck. _why From Daniel.Berger at qwest.com Fri Apr 21 12:25:03 2006 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 21 Apr 2006 11:25:03 -0500 Subject: [Mongrel] "Client closed socket" spewage Message-ID: <39AA6550E5AA554AB1456707D6E5563DBCFF9A@QTOMAE2K3M01.AD.QINTRA.COM> Hi all, Ruby 1.8.4 Rails 1.1.2 Mongrel 0.3.12 I'm seeing this output from the Mongrel server: Client closed socket requesting file C:/eclipse/workspace/dslscheduler/public/javascripts/prototype.js: Invalid argument It seems to be harmless, but I'm curious as to what's causing it. Any ideas? Thanks, Dan From zedshaw at zedshaw.com Fri Apr 21 14:13:28 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 21 Apr 2006 14:13:28 -0400 Subject: [Mongrel] "Client closed socket" spewage In-Reply-To: <39AA6550E5AA554AB1456707D6E5563DBCFF9A@QTOMAE2K3M01.AD.QINTRA.COM> Message-ID: Hi Dan, I added those reports for people who have crappy proxy servers that keep closing the connections. Lighttpd does this quite frequently for no apparent reason. I'm really starting to not like lighttpd. Basically, if the file is being served to the client and the client closes the connection mid-stream then it's usually harmless. It means someone just hit the stop button on their browser. But if you're seeing a ton of these then there's probably something wrong, especially if it's to the same file. Take a look at your proxy server settings and consider blocking remote clients that do this often. Another thing is that, if you have your fronting web server configured right so it deals with the static files, then you should see these for static files at all. This means that Mongrel is actually serving the file when really a web server like apache or litespeed should be doing it. I'll be most likely toning down the logging once it seems that the parser is doing good and people think these closed connection warnings are not needed. Let me know if you also see BAD CLIENT dumps with requests that should be legitimate. Also, there's a pre-release up that dumps more information to help track this stuff down like the IP address of the remote client and the time. You can install it with gem install mongrel --source=http://mongrel.rubyforge.org/releases/ Zed On 4/21/06 12:25 PM, "Berger, Daniel" wrote: > Hi all, > > Ruby 1.8.4 > Rails 1.1.2 > Mongrel 0.3.12 > > I'm seeing this output from the Mongrel server: > > Client closed socket requesting file > C:/eclipse/workspace/dslscheduler/public/javascripts/prototype.js: > Invalid argument > > It seems to be harmless, but I'm curious as to what's causing it. Any > ideas? > > Thanks, > > Dan > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From Daniel.Berger at qwest.com Fri Apr 21 14:25:32 2006 From: Daniel.Berger at qwest.com (Daniel Berger) Date: Fri, 21 Apr 2006 12:25:32 -0600 Subject: [Mongrel] "Client closed socket" spewage In-Reply-To: References: Message-ID: <4449239C.8010006@qwest.com> Thanks for the reply Zed. However, this is just a local server for development. There's no proxy, no frontend web server for serving static content, and no external client (at least, that I know of). Just me futzing around in IE on localhost to make sure everything looks ok. Running the same Rails app on my Solaris box (again, a local dev copy) does not seem to produce this warning. I thought it was a Windows specific issue of some sort. I'll try the prerelease and see if I can get any further information. Thanks, Dan Zed Shaw wrote: > Hi Dan, > > I added those reports for people who have crappy proxy servers that keep > closing the connections. Lighttpd does this quite frequently for no > apparent reason. I'm really starting to not like lighttpd. > > Basically, if the file is being served to the client and the client closes > the connection mid-stream then it's usually harmless. It means someone just > hit the stop button on their browser. > > But if you're seeing a ton of these then there's probably something wrong, > especially if it's to the same file. Take a look at your proxy server > settings and consider blocking remote clients that do this often. > > Another thing is that, if you have your fronting web server configured right > so it deals with the static files, then you should see these for static > files at all. This means that Mongrel is actually serving the file when > really a web server like apache or litespeed should be doing it. > > I'll be most likely toning down the logging once it seems that the parser is > doing good and people think these closed connection warnings are not needed. > Let me know if you also see BAD CLIENT dumps with requests that should be > legitimate. > > Also, there's a pre-release up that dumps more information to help track > this stuff down like the IP address of the remote client and the time. You > can install it with gem install mongrel > --source=http://mongrel.rubyforge.org/releases/ > > > Zed > > > On 4/21/06 12:25 PM, "Berger, Daniel" wrote: > >> Hi all, >> >> Ruby 1.8.4 >> Rails 1.1.2 >> Mongrel 0.3.12 >> >> I'm seeing this output from the Mongrel server: >> >> Client closed socket requesting file >> C:/eclipse/workspace/dslscheduler/public/javascripts/prototype.js: >> Invalid argument >> >> It seems to be harmless, but I'm curious as to what's causing it. Any >> ideas? >> >> Thanks, >> >> Dan >> >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From zedshaw at zedshaw.com Fri Apr 21 14:29:17 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 21 Apr 2006 14:29:17 -0400 Subject: [Mongrel] "Client closed socket" spewage In-Reply-To: Message-ID: On 4/21/06 2:13 PM, "Zed Shaw" wrote: > Another thing is that, if you have your fronting web server configured right > so it deals with the static files, then you should see these for static > files at all. This means that Mongrel is actually serving the file when > really a web server like apache or litespeed should be doing it. Correction: "then you should *NOT* see these for static file at all." Zed From Daniel.Berger at qwest.com Fri Apr 21 15:13:29 2006 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 21 Apr 2006 14:13:29 -0500 Subject: [Mongrel] "Client closed socket" spewage Message-ID: <39AA6550E5AA554AB1456707D6E5563DBCFF9D@QTOMAE2K3M01.AD.QINTRA.COM> > -----Original Message----- > From: mongrel-users-bounces at rubyforge.org > [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed Shaw > Sent: Friday, April 21, 2006 12:13 PM > To: mongrel-users at rubyforge.org > Subject: Re: [Mongrel] "Client closed socket" spewage > > Also, there's a pre-release up that dumps more information to > help track this stuff down like the IP address of the remote > client and the time. You can install it with gem install > mongrel --source=http://mongrel.rubyforge.org/releases/ I seem to be having some problems: C:\>gem install mongrel --source=http://mongrel.rubyforge.org/releases/ Attempting local installation of 'mongrel' Local gem file not found: mongrel*.gem Attempting remote installation of 'mongrel' Install required dependency daemons? [Yn] Y ERROR: While executing gem ... (Gem::GemNotFoundException) Could not find daemons (>= 0.4.2) in the repository Gem issue? I didn't think Windows had daemons as a prereq. Regards, Dan From bryan.a.soto at gmail.com Fri Apr 21 15:33:15 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 12:33:15 -0700 Subject: [Mongrel] "Client closed socket" spewage In-Reply-To: <39AA6550E5AA554AB1456707D6E5563DBCFF9D@QTOMAE2K3M01.AD.QINTRA.COM> References: <39AA6550E5AA554AB1456707D6E5563DBCFF9D@QTOMAE2K3M01.AD.QINTRA.COM> Message-ID: On 4/21/06, Berger, Daniel wrote: > > -----Original Message----- > > From: mongrel-users-bounces at rubyforge.org > > [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed Shaw > > Sent: Friday, April 21, 2006 12:13 PM > > To: mongrel-users at rubyforge.org > > Subject: Re: [Mongrel] "Client closed socket" spewage > > > > > Also, there's a pre-release up that dumps more information to > > help track this stuff down like the IP address of the remote > > client and the time. You can install it with gem install > > mongrel --source=http://mongrel.rubyforge.org/releases/ > > I seem to be having some problems: > > C:\>gem install mongrel --source=http://mongrel.rubyforge.org/releases/ > Attempting local installation of 'mongrel' > Local gem file not found: mongrel*.gem > Attempting remote installation of 'mongrel' > Install required dependency daemons? [Yn] Y > ERROR: While executing gem ... (Gem::GemNotFoundException) > Could not find daemons (>= 0.4.2) in the repository > > Gem issue? I didn't think Windows had daemons as a prereq. > The fun of serving beta gems. You might have better luck running C:\> gem install mongrel then C:\> gem update mongrel --source=http://mongrel.rubyforge.org/releases that way all the dependencies are installed. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Fri Apr 21 15:39:13 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 12:39:13 -0700 Subject: [Mongrel] "Client closed socket" spewage In-Reply-To: References: <39AA6550E5AA554AB1456707D6E5563DBCFF9D@QTOMAE2K3M01.AD.QINTRA.COM> Message-ID: On 4/21/06, Bryan Soto wrote: > > I seem to be having some problems: > > > > C:\>gem install mongrel --source=http://mongrel.rubyforge.org/releases/ > > Attempting local installation of 'mongrel' > > Local gem file not found: mongrel*.gem > > Attempting remote installation of 'mongrel' > > Install required dependency daemons? [Yn] Y > > ERROR: While executing gem ... (Gem::GemNotFoundException) > > Could not find daemons (>= 0.4.2) in the repository > > > > Gem issue? I didn't think Windows had daemons as a prereq. > > > > The fun of serving beta gems. You might have better luck running > C:\> gem install mongrel > then > C:\> gem update mongrel --source=http://mongrel.rubyforge.org/releases > that way all the dependencies are installed. > And follow that with a C:\> gem cleanup mongrel Hope that helps, Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From zedshaw at zedshaw.com Fri Apr 21 19:06:32 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 21 Apr 2006 19:06:32 -0400 Subject: [Mongrel] "Client closed socket" spewage In-Reply-To: <39AA6550E5AA554AB1456707D6E5563DBCFF9D@QTOMAE2K3M01.AD.QINTRA.COM> Message-ID: Ah, see what happens when you don't test? Thanks Brian for clueing Dan in. Dan, let me know how this works. Zed On 4/21/06 3:13 PM, "Berger, Daniel" wrote: >> -----Original Message----- >> From: mongrel-users-bounces at rubyforge.org >> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed Shaw >> Sent: Friday, April 21, 2006 12:13 PM >> To: mongrel-users at rubyforge.org >> Subject: Re: [Mongrel] "Client closed socket" spewage > >> >> Also, there's a pre-release up that dumps more information to >> help track this stuff down like the IP address of the remote >> client and the time. You can install it with gem install >> mongrel --source=http://mongrel.rubyforge.org/releases/ > > I seem to be having some problems: > > C:\>gem install mongrel --source=http://mongrel.rubyforge.org/releases/ > Attempting local installation of 'mongrel' > Local gem file not found: mongrel*.gem > Attempting remote installation of 'mongrel' > Install required dependency daemons? [Yn] Y > ERROR: While executing gem ... (Gem::GemNotFoundException) > Could not find daemons (>= 0.4.2) in the repository > > Gem issue? I didn't think Windows had daemons as a prereq. > > Regards, > > Dan > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From luislavena at gmail.com Fri Apr 21 19:17:59 2006 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 21 Apr 2006 20:17:59 -0300 Subject: [Mongrel] "Client closed socket" spewage In-Reply-To: References: <39AA6550E5AA554AB1456707D6E5563DBCFF9D@QTOMAE2K3M01.AD.QINTRA.COM> Message-ID: <71166b3b0604211617p22b9b415qdd15359a6be8a5fa@mail.gmail.com> On 4/21/06, Zed Shaw wrote: > Ah, see what happens when you don't test? Thanks Brian for clueing Dan in. > Dan, let me know how this works. Zed, beta gems are *nix only, right? Thats why the dependencies are broken... Let me know the release schedule and the todo so we could work better, with test on the win32 side of mongrel. Luis From zedshaw at zedshaw.com Fri Apr 21 19:29:01 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 21 Apr 2006 19:29:01 -0400 Subject: [Mongrel] "Client closed socket" spewage In-Reply-To: <71166b3b0604211617p22b9b415qdd15359a6be8a5fa@mail.gmail.com> Message-ID: Yeah, beta gems tend to only release for the posix side of things because, ehem, I'm a lazy bastard. I'll do up a better release. I'll get ahold of you soon about cleaning up the win32 side of things so that everything is nice and unified into one simple script. Zed On 4/21/06 7:17 PM, "Luis Lavena" wrote: > On 4/21/06, Zed Shaw wrote: >> Ah, see what happens when you don't test? Thanks Brian for clueing Dan in. >> Dan, let me know how this works. > > Zed, beta gems are *nix only, right? Thats why the dependencies are broken... > > Let me know the release schedule and the todo so we could work better, > with test on the win32 side of mongrel. > > Luis > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From zedshaw at zedshaw.com Fri Apr 21 19:30:08 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 21 Apr 2006 19:30:08 -0400 Subject: [Mongrel] "Client closed socket" spewage In-Reply-To: <4449239C.8010006@qwest.com> Message-ID: Dan, sorry but I totally forgot that you're on win32. Not a good brain day for me. Let me test this all out tonight and get back to you. I'll post beta gems that you can get from the win32 side too. Zed On 4/21/06 2:25 PM, "Daniel Berger" wrote: > > I'll try the prerelease and see if I can get any further information. > > Thanks, > From jeremy at jthopple.com Fri Apr 28 10:48:51 2006 From: jeremy at jthopple.com (Jeremy Hopple) Date: Fri, 28 Apr 2006 08:48:51 -0600 Subject: [Mongrel] Nightly mongrel issues... Message-ID: Hi, I have Apache (2.2) setup to proxy requests through to Mongrel (0.3.12.4) for a Rails (1.1.2) application (on ruby 1.8.4). The setup is great, but I'm experiencing some nightly failures. I thought I'd post here before digging in too deeply, but it looks like Rails is going into lala land and Mongrel can't recover... Seems like everything gets all backed up in mongrel/rails.rb:64 at: @guard.synchronize do # Rails is not thread safe so must be run entirely within synchronize Dispatcher.dispatch(cgi, ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS, response.body) end Prior to doing a "mongrel_rails restart" the mongrel log is normal and there's nothing unusual in my rails log. Once I do a "mongrel_rails restart," I get a bunch of the following dumped into the mongrel.log (I assume one for each thread that's chillin' at @guard.synchronize)... Error calling Dispatcher.dispatch # /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:472:in`lock' /usr/local/lib/ruby/1.8/thread.rb:133:in `synchronize' /usr/local/lib/ruby/gems/1.8/gems/mongrel- 0.3.12.4/lib/mongrel/rails.rb:64:in `process' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:425:in`process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:424:in`process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:495:in`run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:494:in`run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:483:in`run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:774:in`run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:772:in`run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/bin/mongrel_rails:97:in`run' /usr/local/lib/ruby/gems/1.8/gems/mongrel- 0.3.12.4/lib/mongrel/command.rb:163:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/bin/mongrel_rails:194 /usr/local/bin/mongrel_rails:18 If anyone has any ideas please let me know... I promise I'll jump up and down! Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060428/a844270e/attachment.htm From zedshaw at zedshaw.com Sat Apr 29 15:33:09 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sat, 29 Apr 2006 15:33:09 -0400 Subject: [Mongrel] Nightly mongrel issues... In-Reply-To: Message-ID: Usually this happens if you have a Rails handler that gets to a point and then stops for some reason. Since Mongrel has a lock around the dispatcher, and you?ve got an action that isn?t exiting, then all subsequent requests will become jammed. Typical things that can do this are not closing files, forking or spawning processes and not waiting for them, connecting to remote servers that don?t answer right away, and even opening too many files. Look for any actions which could possibly cause something like this, especially if you?re using an external program to do some processing. I?ve added a ?B option and also created a small set of debugging handlers which dump lots of information for you. It slows your application down, so the best way to do it is this: 1. Run mongrel with ?B so it dumps thread, memory, etc. information to log/mongrel_debug/*.log files. 2. Write a Watir or Selenium test that goes through your application like a user. 3. Run the test and watch the mongrel_debug logs, paying attention to the ones reporting files and threads. 4. If you see an action that seems to have lots of objects created, lots of threads left open, or dangling files then that?s probably the one. 5. Go in and fix it. If you?re able to let me view your code, I?d like to work through this with you. It?s a very common problem but I?d like to go through helping someone fix it. Can you get together with me at some point? Zed On 4/28/06 10:48 AM, "Jeremy Hopple" wrote: > Hi, > > I have Apache (2.2) setup to proxy requests through to Mongrel (0.3.12.4 > ) for a Rails (1.1.2) application (on ruby 1.8.4). The > setup is great, but I'm experiencing some nightly failures. I thought I'd > post here before digging in too deeply, but it looks like Rails is going into > lala land and Mongrel can't recover... > > Seems like everything gets all backed up in mongrel/rails.rb:64 at: > > @guard.synchronize do > # Rails is not thread safe so must be run entirely within > synchronize > Dispatcher.dispatch (cgi, > ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS, response.body) > end > > Prior to doing a "mongrel_rails restart" the mongrel log is normal and there's > nothing unusual in my rails log. Once I do a "mongrel_rails restart," I get a > bunch of the following dumped into the mongrel.log (I assume one for each > thread that's chillin' at @guard.synchronize)... > > Error calling Dispatcher.dispatch # > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 0.3.12.4/lib/mongrel.rb:472:in > `lock' > /usr/local/lib/ruby/1.8/thread.rb:133:in `synchronize' > /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel/rails.rb:64:in > `process' > /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:425:in > `process_client' > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 0.3.12.4/lib/mongrel.rb:424:in > `process_client' > /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:495:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 0.3.12.4/lib/mongrel.rb:494:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:483:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/lib/mongrel.rb:774:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 0.3.12.4/lib/mongrel.rb:772:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/bin/mongrel_rails:97:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/mongrel- > 0.3.12.4/lib/mongrel/command.rb:163:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.12.4/bin/mongrel_rails:194 > > /usr/local/bin/mongrel_rails:18 > > If anyone has any ideas please let me know... I promise I'll jump up and down! > > Thanks, > Jeremy > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060429/dded364a/attachment.htm From jeremy at jthopple.com Sat Apr 29 18:44:08 2006 From: jeremy at jthopple.com (Jeremy Hopple) Date: Sat, 29 Apr 2006 16:44:08 -0600 Subject: [Mongrel] Nightly mongrel issues... In-Reply-To: References: Message-ID: Zed, Thanks for getting back to me and I really appreciate all the hard work you've put into Mongrel. A little bit more background. I'm in the process of setting up a new, dedicated FC4 machine to host 3 applications that I'm getting ready to release. None of them are live yet, but I have two of them in a "staging" environment on the new server for testing. Both of the applications I have running on the new server have exhibited the same behavior multiple times. Also, they both have done this upon the first request after a long period of inactivity (i.e. while we're sleeping). Unless one of the members of my team is testing the application or it's being load tested, the apps are idle. This problem has never happened we were actively using the application, or had the application under load... only when we send a request to it for the first time in the morning. The one thing I did realize this morning is that I had not installed the latest mysql bindings on the server, so I gem installed mysql (2.7). To tell you the truth, I'm not sure which bindings were installed prior to that (ruby and mysql were both installed from the fedora yum repositories). I'm wondering if something was dying in Rails when it tries to connect to mysql after a long period of inactivity... The simpler of the two applications that this is happening with is a very basic event system we put together to publish arts and entertainment happenings in our local community. If you'd like to check it out, we're currently testing it at http://staging.the-j-list.com. This application is very simple. It uses a mysql (5.0.18) and sends a few emails with ActionMailer (using a remote smtp server). Prior to launching mongrel in debug mode, the only file it opens is the production.log. Assuming nothing above rings any bells, I'd be thrilled to get together with you and review the code. I live only about 2 blocks from my office, so I can be here pretty much whenever and we're in Mountain Daylight Time. Also, I can get you access to the svn repository. Thanks again, and let me know what works for you. Jeremy On 4/29/06, Zed Shaw wrote: > > Usually this happens if you have a Rails handler that gets to a point and > then stops for some reason. Since Mongrel has a lock around the dispatcher, > and you've got an action that isn't exiting, then all subsequent requests > will become jammed. > > Typical things that can do this are not closing files, forking or spawning > processes and not waiting for them, connecting to remote servers that don't > answer right away, and even opening too many files. Look for any actions > which could possibly cause something like this, especially if you're using > an external program to do some processing. > > I've added a ?B option and also created a small set of debugging handlers > which dump lots of information for you. It slows your application down, so > the best way to do it is this: > > > 1. Run mongrel with ?B so it dumps thread, memory, etc. information > to log/mongrel_debug/*.log files. > 2. Write a Watir or Selenium test that goes through your application > like a user. > 3. Run the test and watch the mongrel_debug logs, paying attention > to the ones reporting files and threads. > 4. If you see an action that seems to have lots of objects created, > lots of threads left open, or dangling files then that's probably the one. > 5. Go in and fix it. > > > If you're able to let me view your code, I'd like to work through this > with you. It's a *very* common problem but I'd like to go through helping > someone fix it. Can you get together with me at some point? > > Zed > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060429/90097d03/attachment-0001.htm From rsaccon at gmail.com Sun Apr 30 03:52:55 2006 From: rsaccon at gmail.com (Roberto Saccon) Date: Sun, 30 Apr 2006 04:52:55 -0300 Subject: [Mongrel] restart with capistrano Message-ID: Hi all I bumped into the following issue: when trying to restart with capistrano, it does restart, but with the app from the old deployment directory. desc "Restart the app server." task :restart, :roles => :app do run "mongrel_rails restart -c #{current_release}" end Has anybody a better solution for that ? -- Roberto Saccon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060430/2def4fc2/attachment.htm From dansketcher at gmail.com Sun Apr 30 03:59:28 2006 From: dansketcher at gmail.com (Dan Sketcher) Date: Sun, 30 Apr 2006 17:59:28 +1000 Subject: [Mongrel] restart with capistrano In-Reply-To: References: Message-ID: <17ed515b0604300059x39463364td5668aff51072d43@mail.gmail.com> Yep! http://www.dansketcher.com/2006/04/26/capistrano-mongrel-and-mongrel_cluster/ From rsaccon at gmail.com Sun Apr 30 04:11:38 2006 From: rsaccon at gmail.com (Roberto Saccon) Date: Sun, 30 Apr 2006 05:11:38 -0300 Subject: [Mongrel] restart with capistrano In-Reply-To: <17ed515b0604300059x39463364td5668aff51072d43@mail.gmail.com> References: <17ed515b0604300059x39463364td5668aff51072d43@mail.gmail.com> Message-ID: Thanks very much On 4/30/06, Dan Sketcher wrote: > > Yep! > > > http://www.dansketcher.com/2006/04/26/capistrano-mongrel-and-mongrel_cluster/ > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Roberto Saccon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060430/46429e05/attachment.htm From zedshaw at zedshaw.com Sun Apr 30 15:59:24 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 30 Apr 2006 15:59:24 -0400 Subject: [Mongrel] Nightly mongrel issues... In-Reply-To: Message-ID: Hey Jeremy, Comments below... On 4/29/06 6:44 PM, "Jeremy Hopple" wrote: > > Zed, > > Thanks for getting back to me and I really appreciate all the hard work you've > put into Mongrel. > > A little bit more background. I'm in the process of setting up a new, > dedicated FC4 machine to host 3 applications that I'm getting ready to > release. None of them are live yet, but I have two of them in a "staging" > environment on the new server for testing. > > Both of the applications I have running on the new server have exhibited the > same behavior multiple times. Also, they both have done this upon the first > request after a long period of inactivity (i.e. while we're sleeping). Unless > one of the members of my team is testing the application or it's being load > tested, the apps are idle. > Ah, I'm thinking this is mysql's lame ass connection crap. Rails opens connections to the database and just leaves them there. Since TCP has a timeout, and mysql doesn't have a heartbeat element to the protocol, your connections will time out and things go bad. > The one thing I did realize this morning is that I had not installed the > latest mysql bindings on the server, so I gem installed mysql ( 2.7). To tell > you the truth, I'm not sure which bindings were installed prior to that (ruby > and mysql were both installed from the fedora yum repositories). I'm wondering > if something was dying in Rails when it tries to connect to mysql after a long > period of inactivity... > Yes, I sent another e-mail off-list, but the default mysql.rb that rails has is total junk. Always install the mysql native compiled gem, this is also a performance boost. > The simpler of the two applications that this is happening with is a very > basic event system we put together to publish arts and entertainment > happenings in our local community. If you'd like to check it out, we're > currently testing it at http://staging.the-j-list.com. This application is > very simple. It uses a mysql (5.0.18) and sends a few emails with > ActionMailer (using a remote smtp server). Prior to launching mongrel in > debug mode, the only file it opens is the production.log. > It seems like the mysql tcp connection is dying during the night. I'd be curious to know if this same problem happens under webrick. In theory it should since this would be a rails driver problem. Another thing is, why mysql? Maybe another database like postgresql doesn't have these problems. I've been using postgresql in my apps and I don't any of these problems. > Assuming nothing above rings any bells, I'd be thrilled to get together with > you and review the code. I live only about 2 blocks from my office, so I can > be here pretty much whenever and we're in Mountain Daylight Time. Also, I can > get you access to the svn repository. > Yeah, I've got a mongrel version going out tonight (hopefully), so I'll try to catch you when I can either tonight or tomorrow. Zed From jason at joyent.com Sun Apr 30 16:23:07 2006 From: jason at joyent.com (Jason Hoffman) Date: Sun, 30 Apr 2006 13:23:07 -0700 Subject: [Mongrel] Nightly mongrel issues... In-Reply-To: References: Message-ID: <026C046A-50E5-4446-B739-CEFE22032DD2@joyent.com> > It seems like the mysql tcp connection is dying during the night. > I'd be interactive_timeout in mysql defaults to 28800 seconds (480 minutes or 8 hours). So what you're experiencing is that you probably stop touching the app at about 4pm, go home for the day and then mysql closes those connections at about midnight. If you set interactive_timeout = 86400 in a my.cnf file then what you're experiencing would go away. But it should be clear why lower values are a good thing in a production application. You can read about interactive_timeout and wait_timeout at http:// dev.mysql.com/doc/refman/5.0/en/server-system-variables.html - J