From philippe.lachaise at gmail.com Fri Sep 1 03:48:14 2006 From: philippe.lachaise at gmail.com (philippe lachaise) Date: Fri, 1 Sep 2006 09:48:14 +0200 Subject: [Mongrel] Rails Deployment Book In-Reply-To: <525964E9-B3F1-4D9C-9985-95B1837D020F@eastmedia.com> References: <20060831232817.57160.qmail@web38605.mail.mud.yahoo.com> <78A57C81-572B-45F4-B6CD-03ADACE16501@mac.com> <525964E9-B3F1-4D9C-9985-95B1837D020F@eastmedia.com> Message-ID: >> What you need to know from a tool is: could I start form zero? I mean, >> with small things? >> It could be adaptable/scalable for greater things later during the process? >> Maybe 1 year from now, it could be maintainable? could be bug fixed? >> feature enhanced? This entirely describes my own expectations. Can anywone write the book that answers this set of questions ? Count me as a buyer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060901/c3d7b6b2/attachment.html From paul at paulbutcher.com Fri Sep 1 05:53:39 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Fri, 1 Sep 2006 10:53:39 +0100 Subject: [Mongrel] Configuring Mongrel logging Message-ID: <002701c6cdac$80390f90$5f01a8c0@paullaptop> Is there any way to configure Mongrel's logging? Specifically, I'd like to get it to output to syslog. Our Rails apps already do this (via SyslogLogger) - is there any way to persuade Mongrel to do the same? Thanks! -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From tperrett at butlerandtanner.com Fri Sep 1 07:54:30 2006 From: tperrett at butlerandtanner.com (Tim Perrett) Date: Fri, 01 Sep 2006 12:54:30 +0100 Subject: [Mongrel] Application performance Message-ID: Hey all Im working on improving the speed of my application. Ive taken on board everything that has been said on this forum so far, im using httperf to benchmark and try to improve performance. However, I have some question marks over how best to go about improving performance in certain areas.... With no caching or such like deployed the application runs at an rather slow 35 - 38 req/s. A static file from the server runs at 872 req/s - so im rather far behind that. A basic rails app with render text runs at around 200 req/s. So realistically there is a lot more tuning to be done to get it to a decent level. Im guessing it changes from app to app but if I aim to get near 100 req/s that would improve performance to the point of being much quicker for users? The nature of the application is such that its difficult to do a lot of caching in the traditional sense, is there anyway I can make a custom caching mechanism to cache the content in the way I want? Many thanks in advance Tim ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ From gethemant at gmail.com Fri Sep 1 08:06:10 2006 From: gethemant at gmail.com (hemant) Date: Fri, 1 Sep 2006 17:36:10 +0530 Subject: [Mongrel] mongrel thread safety and global variables Message-ID: In environment.rb file, I initialize a connection to some data vending servers, through TCP sockets. The connection object is global and hence the code: #environment.rb $generic_connection = ConnectionClass.instance (singleton class) $generic_connection.connect_me( this call will make the connection) The above approach is to make sure that, only one connection is made to the data vending servers.ConnectionClass is a library Class that, I have written to handle connections and to ensure exception handling and all that stuff. Now, in our rails code, whenever we need some data from these data vending servers, we use this global variable to get the data. #in controllers $generic_connection.get_data('') Since, we switched to mongrel, we are facing a strange issue. Our protocol code, specify what kind of data we want from data vending servers.So, lets say we want, x informatio, then we specify xxx as protocol code and get the data. protocol code "yyy" would give completely different kind of data. Now..sometimes what happens is, an Ajax call requests xxx protocol code and in the response we get data of protocol code yyy. Data vending servers are threaded again, and for each connection it starts a new thread and each request is served on a new thread. Data vending servers are again mostly written in ruby. Now, I am wondering where is the problem? As i know, mongrel serves requests on new threads, so what happens to this global variable that is shared among the threads.Is there a possiblity that, problem is here? I mean, lets say a thread is using this global variable for fetching data for protocol code xxx and same time another thread requests for protocol code yyy. My connection class, which is basically a proxy to these data vending servers, may not be thread safe.If this is the problem, then can anybody suggest better approach of making single connection to data vending servers, without using shared global variables. It could be a problem with our data vending servers also.But I am not so, sure about that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060901/7313c88e/attachment.html From jason at joyent.com Fri Sep 1 08:08:21 2006 From: jason at joyent.com (Jason A. Hoffman) Date: Fri, 1 Sep 2006 05:08:21 -0700 Subject: [Mongrel] Application performance In-Reply-To: References: Message-ID: On Sep 1, 2006, at 4:54 AM, Tim Perrett wrote: > Hey all > > Im working on improving the speed of my application. Ive taken on > board > everything that has been said on this forum so far, im using > httperf to > benchmark and try to improve performance. However, I have some > question > marks over how best to go about improving performance in certain > areas.... > > With no caching or such like deployed the application runs at an > rather slow > 35 - 38 req/s. A static file from the server runs at 872 req/s - so im > rather far behind that. A basic rails app with render text runs at > around > 200 req/s. So realistically there is a lot more tuning to be done > to get it > to a decent level. Im guessing it changes from app to app but if I > aim to > get near 100 req/s that would improve performance to the point of > being much > quicker for users? > > The nature of the application is such that its difficult to do a > lot of > caching in the traditional sense, is there anyway I can make a custom > caching mechanism to cache the content in the way I want? > > Many thanks in advance > > Tim Not that it answer's your question directly but just offer the perspective that http://weblog.textdrive.com/article/73/sencers-caching-plugin-for- textpattern-is-snazzy PHP-MySQL based textpattern is "fast" at ~30 req/sec on a single CPU'ed server. And if we put the 35-38 req/sec in the context of how much you're serving. Let's say that text+javascript+images+?? = 125 kilobytes per page, and let's assume that you're app is serving 30 req/second. 30req/sec x 125kb page = 3,750 kb/sec = 3.75 MB/sec => 3.75 MB/sec x 60 sec/minute x 60minutes/hour x 24 hours/day = 324,000 MB/day = 324 GB/day So 30 req/sec is 324 GB of network bandwidth out per day; in a 30 day month it's 9720 GBs or 9.72 TBs or 30Mbps constant. Is that at about where you'll be? Is this one mongrel process you're talking about? Now that's also a different issue from being "much quicker for users", that's page latency not req/second throughput. - Jason From jason at joyent.com Fri Sep 1 08:11:22 2006 From: jason at joyent.com (Jason A. Hoffman) Date: Fri, 1 Sep 2006 05:11:22 -0700 Subject: [Mongrel] Application performance In-Reply-To: References: Message-ID: Actually that math is a bit off because it's equating a "page view"/ sec to a request/sec. A page might request 20 things. - Jason On Sep 1, 2006, at 5:08 AM, Jason A. Hoffman wrote: > On Sep 1, 2006, at 4:54 AM, Tim Perrett wrote: >> Hey all >> >> Im working on improving the speed of my application. Ive taken on >> board >> everything that has been said on this forum so far, im using >> httperf to >> benchmark and try to improve performance. However, I have some >> question >> marks over how best to go about improving performance in certain >> areas.... >> >> With no caching or such like deployed the application runs at an >> rather slow >> 35 - 38 req/s. A static file from the server runs at 872 req/s - >> so im >> rather far behind that. A basic rails app with render text runs at >> around >> 200 req/s. So realistically there is a lot more tuning to be done >> to get it >> to a decent level. Im guessing it changes from app to app but if I >> aim to >> get near 100 req/s that would improve performance to the point of >> being much >> quicker for users? >> >> The nature of the application is such that its difficult to do a >> lot of >> caching in the traditional sense, is there anyway I can make a custom >> caching mechanism to cache the content in the way I want? >> >> Many thanks in advance >> >> Tim > > Not that it answer's your question directly but just offer the > perspective that > > http://weblog.textdrive.com/article/73/sencers-caching-plugin-for- > textpattern-is-snazzy > > PHP-MySQL based textpattern is "fast" at ~30 req/sec on a single > CPU'ed server. > > And if we put the 35-38 req/sec in the context of how much you're > serving. Let's say that text+javascript+images+?? = 125 kilobytes per > page, and let's assume that you're app is serving 30 req/second. > > 30req/sec x 125kb page = 3,750 kb/sec = 3.75 MB/sec > > => 3.75 MB/sec x 60 sec/minute x 60minutes/hour x 24 hours/day = > 324,000 MB/day = 324 GB/day > > So 30 req/sec is 324 GB of network bandwidth out per day; in a 30 day > month it's 9720 GBs or 9.72 TBs or 30Mbps constant. > > Is that at about where you'll be? Is this one mongrel process you're > talking about? > > Now that's also a different issue from being "much quicker for > users", that's page latency not req/second throughput. > > - Jason From hip at lan-attack.ch Fri Sep 1 08:42:55 2006 From: hip at lan-attack.ch (Philippe Jayet) Date: Fri, 01 Sep 2006 14:42:55 +0200 Subject: [Mongrel] Setup with Apache 2.2 proxy balancer : timeout during uploads In-Reply-To: <1157061520.7167.8.camel@localhost.localdomain> References: <44F49956.8080308@lan-attack.ch> <44F6E02B.4050003@lan-attack.ch> <1157061520.7167.8.camel@localhost.localdomain> Message-ID: <44F82ACF.1080202@lan-attack.ch> > Yes, Mongrel processes the full request, including uploaded body before > calling rails (and locking it). If the request is large then it also > streams the result to a tmpfile in order to not use up ram. You're doing an amazing job Zed :) > The response Rails generates is placed into an internal buffer and then > when Rails is done Mongrel unlocks rails and spends the rest of it's > time sending back the response. This is necessary so that Rails can be > locked for the shortest amount of time. How does it interact with send_file and send_data? Which method is the best to use to serve files of serveral MB? Thanks for your help, Philippe J. From gethemant at gmail.com Fri Sep 1 08:48:04 2006 From: gethemant at gmail.com (hemant) Date: Fri, 1 Sep 2006 18:18:04 +0530 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: References: Message-ID: On 9/1/06, hemant wrote: > > > In environment.rb file, I initialize a connection to some data vending > servers, through TCP sockets. > > The connection object is global and hence the code: > > #environment.rb > $generic_connection = ConnectionClass.instance (singleton class) > $generic_connection.connect( this call will make the connection) > > > The above approach is to make sure that, only one connection is made to > the data vending servers.ConnectionClass is a library Class that, I have > written to handle connections and to ensure exception handling and all that > stuff. > > Now, in our rails code, whenever we need some data from these data vending > servers, we use this global variable to get the data. > > #in controllers > $generic_connection.get_data('') > > > > Since, we switched to mongrel, we are facing a strange issue. Our protocol > code, specify what kind of data we want from data vending servers.So, lets > say we want, x informatio, then we specify xxx as protocol code and get the > data. protocol code "yyy" would give completely different kind of data. > Now..sometimes what happens is, an Ajax call requests xxx protocol code and > in the response we get data of protocol code yyy. Data vending servers are > threaded again, and for each connection it starts a new thread and each > request is served on a new thread. > Data vending servers are again mostly written in ruby. > > Now, I am wondering where is the problem? > > As i know, mongrel serves requests on new threads, so what happens to this > global variable that is shared among the threads.Is there a possiblity > that, problem is here? > I mean, lets say a thread is using this global variable for fetching data > for protocol code xxx and same time another thread requests for protocol > code yyy. My connection class, which is basically a proxy to these data > vending servers, may not be thread safe.If this is the problem, then can > anybody suggest better approach of making single connection to data vending > servers, without using shared global variables. > > > > It could be a problem with our data vending servers also.But I am not so, > sure about that. > > For anyone interested here is the ConnectionClass code: require 'socket' require 'timeout' require 'singleton' require 'yaml' class ConnectionClass include Singleton def connect p = YAML.load(File.read("#{RAILS_ROOT}/config/parameters.yaml")) @socket_file = p["socket_file"] return connect_to_proxy end def connect_to_proxy begin @proxy_con = UNIXSocket.open(@socket_file.strip) return @proxy_con rescue Exception => e return nil end end def get_data(request_string) req_array = request_string.split(':') code = req_array[0].strip msg = req_array[1].strip symbol = req_array[2].strip return get_data_from_proxy(code,symbol) end def get_data_from_proxy(code,symbol) temp_string = code + '<' + symbol + '>' ret_data = nil begin @proxy_con.puts(temp_string) rescue Errno::EPIPE unless connect_to_proxy.nil? @proxy_con.puts(temp_string) else return nil end rescue Exception => e return nil end begin timeout(8) do ret_data = @proxy_con.gets() end rescue Timeout::Error return nil rescue Exception => e return nil end if ret_data =~ /^600*/ return nil elsif ret_data =~ /^620*/ return nil else return ret_data end end end Evidently, when rails load(i.e mongrel starts), the only call made is, $generic_connection.connect(from environment.rb), and hence within this class, only @proxy_con should be shared among the threads IMHO. So, what happens when subsequent calls to $generic_connection.get_data is made from controller(ie mongrel threads)? while one thread is waiting for @proxy_con.gets, another thread can call the same method, but the question is, both the threads will share local variables defined within get_data and get_data_from_proxy methods? If i make, both the methods threaded, it should solve the problem? but i am wondering, how mongrel would handle it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060901/ae07b793/attachment-0001.html From tperrett at butlerandtanner.com Fri Sep 1 09:08:21 2006 From: tperrett at butlerandtanner.com (Tim Perrett) Date: Fri, 01 Sep 2006 14:08:21 +0100 Subject: [Mongrel] Application performance Message-ID: Ok that's useful!! Its less the bandwidth im worried about (however you do make a very very good point regarding that!) - im more concerned that the application seems really really quick on my internal network, but is quite slow when accessed internally. I just made the assumption that the more requests the application could deliver the quicker the application was, so that's what I was drawing a connection between that, however am I right in saying that? If im needing to boost performance how might one go about doing it? Cheers Tim -------------------------- Not that it answer's your question directly but just offer the perspective that http://weblog.textdrive.com/article/73/sencers-caching-plugin-for- textpattern-is-snazzy PHP-MySQL based textpattern is "fast" at ~30 req/sec on a single CPU'ed server. And if we put the 35-38 req/sec in the context of how much you're serving. Let's say that text+javascript+images+?? = 125 kilobytes per page, and let's assume that you're app is serving 30 req/second. 30req/sec x 125kb page = 3,750 kb/sec = 3.75 MB/sec => 3.75 MB/sec x 60 sec/minute x 60minutes/hour x 24 hours/day = 324,000 MB/day = 324 GB/day So 30 req/sec is 324 GB of network bandwidth out per day; in a 30 day month it's 9720 GBs or 9.72 TBs or 30Mbps constant. Is that at about where you'll be? Is this one mongrel process you're talking about? Now that's also a different issue from being "much quicker for users", that's page latency not req/second throughput. - Jason ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ From gethemant at gmail.com Fri Sep 1 10:02:53 2006 From: gethemant at gmail.com (hemant) Date: Fri, 1 Sep 2006 19:32:53 +0530 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: References: Message-ID: Will, mutex solve the problem? I tried using them and seem to work.But as i said, the problem occurs very less often. There is another problem, if i use Mutex to synchronize, calls, then some calls would take long and time and some would return immediately.so, a request that takes long time, will block the other one. On 9/1/06, hemant wrote: > > On 9/1/06, hemant wrote: > > > > > In environment.rb file, I initialize a connection to some data vending > > servers, through TCP sockets. > > > > The connection object is global and hence the code: > > > > #environment.rb > > $generic_connection = ConnectionClass.instance (singleton class) > > $generic_connection.connect( this call will make the connection) > > > > The above approach is to make sure that, only one connection is made to > the data vending servers.ConnectionClass is a library Class that, I have > written to handle connections and to ensure exception handling and all that > stuff. > > Now, in our rails code, whenever we need some data from these data vending > servers, we use this global variable to get the data. > > #in controllers > $generic_connection.get_data('') > > > > Since, we switched to mongrel, we are facing a strange issue. Our protocol > code, specify what kind of data we want from data vending servers.So, lets > say we want, x informatio, then we specify xxx as protocol code and get the > data. protocol code "yyy" would give completely different kind of data. > Now..sometimes what happens is, an Ajax call requests xxx protocol code and > in the response we get data of protocol code yyy. Data vending servers are > threaded again, and for each connection it starts a new thread and each > request is served on a new thread. > Data vending servers are again mostly written in ruby. > > Now, I am wondering where is the problem? > > As i know, mongrel serves requests on new threads, so what happens to this > global variable that is shared among the threads.Is there a possiblity > that, problem is here? > I mean, lets say a thread is using this global variable for fetching data > for protocol code xxx and same time another thread requests for protocol > code yyy. My connection class, which is basically a proxy to these data > vending servers, may not be thread safe.If this is the problem, then can > anybody suggest better approach of making single connection to data vending > servers, without using shared global variables. > > > > It could be a problem with our data vending servers also.But I am not so, > sure about that. > > > For anyone interested here is the ConnectionClass code: > > require 'socket' > require 'timeout' > require 'singleton' > require 'yaml' > > class ConnectionClass > include Singleton > > def connect > p = YAML.load(File.read("#{RAILS_ROOT}/config/parameters.yaml")) > @socket_file = p["socket_file"] > return connect_to_proxy > end > > > def connect_to_proxy > begin > @proxy_con = UNIXSocket.open(@socket_file.strip) > return @proxy_con > rescue Exception => e > return nil > end > end > > def get_data(request_string) > req_array = request_string.split(':') > code = req_array[0].strip > msg = req_array[1].strip > symbol = req_array[2].strip > > return get_data_from_proxy(code,symbol) > > end > > > def get_data_from_proxy(code,symbol) > temp_string = code + '<' + symbol + '>' > > ret_data = nil > > begin > @proxy_con.puts(temp_string) > rescue Errno::EPIPE > unless connect_to_proxy.nil? > @proxy_con.puts(temp_string) > else > return nil > end > rescue Exception => e > return nil > end > > begin > timeout(8) do > ret_data = @proxy_con.gets() > end > rescue Timeout::Error > return nil > rescue Exception => e > return nil > end > > > if ret_data =~ /^600*/ > return nil > elsif ret_data =~ /^620*/ > return nil > else > return ret_data > end > end > > end > > Evidently, when rails load(i.e mongrel starts), the only call made is, > $generic_connection.connect(from environment.rb), and hence within this > class, only @proxy_con should be shared among the threads IMHO. > So, what happens when subsequent calls to $generic_connection.get_data is > made from controller(ie mongrel threads)? while one thread is waiting for > @proxy_con.gets, another thread can call the same method, but the question > is, both the threads will share local variables defined within get_data and > get_data_from_proxy methods? > > If i make, both the methods threaded, it should solve the problem? but i > am wondering, how mongrel would handle it. > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060901/274bbf9f/attachment.html From wyhaines at gmail.com Fri Sep 1 10:07:27 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Fri, 1 Sep 2006 08:07:27 -0600 Subject: [Mongrel] Application performance In-Reply-To: References: Message-ID: On 9/1/06, Tim Perrett wrote: > If im needing to boost performance how might one go about doing it? 35-38/second can move a lot of traffic, as has been mentioned, so long as it's 35-38/second for your dynamic traffic, and your static files are much, much faster. However, when you benchmark 35-38 requests per second, how many concurrent requests are you handing? Can you get 35-38/second with one request at a time, or do you need several concurrent requests to get that speed? How long does it take to actually render a page from your application, from the time the request goes into Rails to the time that it comes out? That latency can make a big difference in the apparent speed of your application, even if your total throughput is good. As for how to speed up page rendering, is there anything that you query from the database that you can cache to avoid db traffic during a hit? That can make a very significant difference. It doesn't matter if you can render 300 pages per second of plain text if, when you do the required db activity, the db bottlenecks you down to 10% of that. Within your Ruby itself there are some easy things that can make differences. If you use inject() anywhere, benchmark that usage. inject() can be elegant as heck, but it's also often as slow as it is elegant, and it tends to create a lot of junk objects that have to be garbage collected. It can sometimes be phenomenally slow compared to a solution that doesn't use it. Do you do any string creation, aggregating from smaller pieces? Use << instead of +. In hash lookups with strings, hash dups the key. If you give it a frozen string it's faster. If you do a lot of hash lookups this can add up. In general, try to be aware of your frivolous object creation. Ruby isn't terribly slow with object creation, but it's still more expensive to use a new object than to reuse an old one, especially when garbage collection is taken into account. But before you spend too much time on any of that, take a look at what you can do to cache your database transactions in order to minimize them. If that is the bottleneck, everything else is a meager drop in the bucket. Kirk Haines From g.vishnu at gmail.com Fri Sep 1 10:24:49 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Fri, 1 Sep 2006 19:54:49 +0530 Subject: [Mongrel] Making Mongrel play well with Monit Message-ID: Hi! I run a mongrel cluster with 6 mongrels in it. I want to monitor them individually for process hangs (and then restart them) and this is the solution I came up with: Here's my configuration file for monit (/usr/local/etc/monitrc): [snipped relevant bits] ------ #check lighttpd process check process lighttpd with pidfile /var/run/lighttpd.pid start program = "/usr/local/etc/rc.d/lighttpd.sh start" stop program = "/usr/local/etc/rc.d/lighttpd.sh stop" if totalmem > 200.0 MB for 5 cycles then restart group server #check pound process check process pound with pidfile /var/run/pound.pid start program = "/usr/local/etc/rc.d/pound.sh start" stop program = "/usr/local/etc/rc.d/pound.sh stop" if totalmem > 400.0 MB for 5 cycles then restart if failed port 6000 protocol http with timeout 10 seconds then restart group server #check mongrel processes #6001 check process mongrel-6001 with pidfile /home/xxx/sshare/app/log/mongrel.6001.pid start program = "/home/xxx/scripts/mongrel_rails_start 6001" stop program = "/home/xxx/scripts/mongrel_rails_stop 6001" if totalmem > 50.0 MB for 5 cycles then restart if failed port 6001 protocol http with timeout 10 seconds then restart group mongrel #6002 check process mongrel-6002 with pidfile /home/xxx/sshare/app/log/mongrel.6002.pid start program = "/home/xxx/scripts/mongrel_rails_start 6002" stop program = "/home/xxx/scripts/mongrel_rails_stop 6002" if totalmem > 50.0 MB for 5 cycles then restart if failed port 6002 protocol http with timeout 10 seconds then restart group mongrel #6003 check process mongrel-6003 with pidfile /home/xxx/sshare/app/log/mongrel.6003.pid start program = "/home/xxx/scripts/mongrel_rails_start 6003" stop program = "/home/xxx/scripts/mongrel_rails_stop 6003" if totalmem > 50.0 MB for 5 cycles then restart if failed port 6003 protocol http with timeout 10 seconds then restart group mongrel #6004 check process mongrel-6004 with pidfile /home/xxx/sshare/app/log/mongrel.6004.pid start program = "/home/xxx/scripts/mongrel_rails_start 6004" stop program = "/home/xxx/scripts/mongrel_rails_stop 6004" if totalmem > 50.0 MB for 5 cycles then restart if failed port 6004 protocol http with timeout 10 seconds then restart group mongrel #6005 check process mongrel-6005 with pidfile /home/xxx/sshare/app/log/mongrel.6005.pid start program = "/home/xxx/scripts/mongrel_rails_start 6005" stop program = "/home/xxx/scripts/mongrel_rails_stop 6005" if totalmem > 50.0 MB for 5 cycles then restart if failed port 6005 protocol http with timeout 10 seconds then restart group mongrel #6006 check process mongrel-6006 with pidfile /home/xxx/sshare/app/log/mongrel.6006.pid start program = "/home/xxx/scripts/mongrel_rails_start 6006" stop program = "/home/xxx/scripts/mongrel_rails_stop 6006" if totalmem > 50.0 MB for 5 cycles then restart if failed port 6006 protocol http with timeout 10 seconds then restart group mongrel ------ The mongrel_rails_start and mongrel_rails_stop are simple scripts like this: mongrel_rails_start: ------ /usr/local/bin/mongrel_rails start -e production -d -p $1 -P /home/xxx/sshare/app/log/mongrel.$1.pid -c /home/xxx/sshare/app ------ Right. When I do this from the command-line, i.e. /home/xxx/scripts/mongrel_rails_start 6001, etc, it works fine. But when monit tries to start or stop the service, it consistently says "execution failed". I thought it might be the fact that the PATH variable wasn't getting set, so I played around with that, but it's still borked. I tried inserting the "/usr/local/bin/mongrel_rails start" with all the params as the monit command there and that didn't work. I even tried "mongrel_rails cluster::start -c /etc/mongrel_rails/sshare.conf" and that's not working too... (note lighttpd and pound are getting restarted fine, so that's not the issue...) I'm aware this is a more 'monit question', but Zed had suggested on the list sometime back that we do monitoring this way. Is there something I'm doing wrong? Please help me out. Vish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060901/5cae1c0e/attachment-0001.html From jsierles at gmail.com Fri Sep 1 10:37:00 2006 From: jsierles at gmail.com (Joshua Sierles) Date: Fri, 1 Sep 2006 09:37:00 -0500 Subject: [Mongrel] Making Mongrel play well with Monit In-Reply-To: References: Message-ID: <722f07be0609010737i3a131c03t241d927ccce3bca7@mail.gmail.com> We're using monit successfully with mongrel, just as you have it configured here. The only different is that we specify the document root explicitly with the -r option to mongrel_start (-r /home/app/public ). Perhaps when running from the command ilne, you did so from the root directory. Josh On 9/1/06, Vishnu Gopal wrote: > Hi! > > I run a mongrel cluster with 6 mongrels in it. I want to monitor them > individually for process hangs (and then restart them) and this is the > solution I came up with: > > Here's my configuration file for monit (/usr/local/etc/monitrc): [snipped > relevant bits] > > ------ > > #check lighttpd process > check process lighttpd with pidfile /var/run/lighttpd.pid > start program = "/usr/local/etc/rc.d/lighttpd.sh start" > stop program = "/usr/local/etc/rc.d/lighttpd.sh stop" > if totalmem > 200.0 MB for 5 cycles then restart > group server > > #check pound process > check process pound with pidfile /var/run/pound.pid > start program = "/usr/local/etc/rc.d/pound.sh start" > stop program = "/usr/local/etc/rc.d/pound.sh stop" > if totalmem > 400.0 MB for 5 cycles then restart > if failed port 6000 protocol http > with timeout 10 seconds > then restart > group server > > #check mongrel processes > > #6001 > check process mongrel-6001 with pidfile > /home/xxx/sshare/app/log/mongrel.6001.pid > start program = "/home/xxx/scripts/mongrel_rails_start > 6001" > stop program = "/home/xxx/scripts/mongrel_rails_stop > 6001" > if totalmem > 50.0 MB for 5 cycles then restart > if failed port 6001 protocol http > with timeout 10 seconds > then restart > group mongrel > > #6002 > check process mongrel-6002 with pidfile > /home/xxx/sshare/app/log/mongrel.6002.pid > start program = "/home/xxx/scripts/mongrel_rails_start > 6002" > stop program = "/home/xxx/scripts/mongrel_rails_stop > 6002" > if totalmem > 50.0 MB for 5 cycles then restart > if failed port 6002 protocol http > with timeout 10 seconds > then restart > group mongrel > > #6003 > check process mongrel-6003 with pidfile > /home/xxx/sshare/app/log/mongrel.6003.pid > start program = "/home/xxx/scripts/mongrel_rails_start > 6003" > stop program = "/home/xxx/scripts/mongrel_rails_stop > 6003" > if totalmem > 50.0 MB for 5 cycles then restart > if failed port 6003 protocol http > with timeout 10 seconds > then restart > group mongrel > > #6004 > check process mongrel-6004 with pidfile > /home/xxx/sshare/app/log/mongrel.6004.pid > start program = "/home/xxx/scripts/mongrel_rails_start > 6004" > stop program = "/home/xxx/scripts/mongrel_rails_stop > 6004" > if totalmem > 50.0 MB for 5 cycles then restart > if failed port 6004 protocol http > with timeout 10 seconds > then restart > group mongrel > > #6005 > check process mongrel-6005 with pidfile > /home/xxx/sshare/app/log/mongrel.6005.pid > start program = "/home/xxx/scripts/mongrel_rails_start > 6005" > stop program = "/home/xxx/scripts/mongrel_rails_stop > 6005" > if totalmem > 50.0 MB for 5 cycles then restart > if failed port 6005 protocol http > with timeout 10 seconds > then restart > group mongrel > > #6006 > check process mongrel-6006 with pidfile > /home/xxx/sshare/app/log/mongrel.6006.pid > start program = "/home/xxx/scripts/mongrel_rails_start > 6006" > stop program = "/home/xxx/scripts/mongrel_rails_stop > 6006" > if totalmem > 50.0 MB for 5 cycles then restart > if failed port 6006 protocol http > with timeout 10 seconds > then restart > group mongrel > > ------ > > The mongrel_rails_start and mongrel_rails_stop are simple scripts like this: > > mongrel_rails_start: > > ------ > > /usr/local/bin/mongrel_rails start -e production -d -p $1 -P > /home/xxx/sshare/app/log/mongrel.$1.pid -c > /home/xxx/sshare/app > > ------ > > Right. When I do this from the command-line, i.e. > /home/xxx/scripts/mongrel_rails_start 6001, etc, it works > fine. But when monit tries to start or stop the service, it consistently > says "execution failed". I thought it might be the fact that the PATH > variable wasn't getting set, so I played around with that, but it's still > borked. I tried inserting the "/usr/local/bin/mongrel_rails start" with all > the params as the monit command there and that didn't work. I even tried > "mongrel_rails cluster::start -c /etc/mongrel_rails/sshare.conf" and that's > not working too... (note lighttpd and pound are getting restarted fine, so > that's not the issue...) > > I'm aware this is a more 'monit question', but Zed had suggested on the list > sometime back that we do monitoring this way. > > Is there something I'm doing wrong? Please help me out. > > Vish > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From ezmobius at gmail.com Fri Sep 1 11:58:09 2006 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Fri, 1 Sep 2006 08:58:09 -0700 Subject: [Mongrel] Application performance In-Reply-To: References: Message-ID: <48A76CF9-8886-4DF4-B147-4991FEA79C17@brainspl.at> HI~ On Sep 1, 2006, at 7:07 AM, Kirk Haines wrote: > On 9/1/06, Tim Perrett wrote: > >> If im needing to boost performance how might one go about doing it? > > 35-38/second can move a lot of traffic, as has been mentioned, so long > as it's 35-38/second for your dynamic traffic, and your static files > are much, much faster. > > However, when you benchmark 35-38 requests per second, how many > concurrent requests are you handing? Can you get 35-38/second with > one request at a time, or do you need several concurrent requests to > get that speed? How long does it take to actually render a page from > your application, from the time the request goes into Rails to the > time that it comes out? > > That latency can make a big difference in the apparent speed of your > application, even if your total throughput is good. > > As for how to speed up page rendering, is there anything that you > query from the database that you can cache to avoid db traffic during > a hit? That can make a very significant difference. It doesn't > matter if you can render 300 pages per second of plain text if, when > you do the required db activity, the db bottlenecks you down to 10% of > that. > > Within your Ruby itself there are some easy things that can make > differences. > > If you use inject() anywhere, benchmark that usage. inject() can be > elegant as heck, but it's also often as slow as it is elegant, and it > tends to create a lot of junk objects that have to be garbage > collected. It can sometimes be phenomenally slow compared to a > solution that doesn't use it. > > Do you do any string creation, aggregating from smaller pieces? Use > << instead of +. > > In hash lookups with strings, hash dups the key. If you give it a > frozen string it's faster. If you do a lot of hash lookups this can > add up. > > In general, try to be aware of your frivolous object creation. Ruby > isn't terribly slow with object creation, but it's still more > expensive to use a new object than to reuse an old one, especially > when garbage collection is taken into account. > > But before you spend too much time on any of that, take a look at what > you can do to cache your database transactions in order to minimize > them. If that is the bottleneck, everything else is a meager drop in > the bucket. > > > Kirk Haines Very good stuff Kirk. I'll mention a few things from my attempts to speed up rails applications. When you look at a rails app like the one being discussed you need to realize that the view templates are getting rendered every hit if there is no caching. How heavy are your views? Using a ton of link_to and all the other helpers is very nice to work with but can kill your performance. I am workign on an app with almost no caching and tons of ajax. After benchmarking it turned out that rendering the view templates was actually taking around 60% of the total time rails spent servicing a request. By switching a number of link_to's into 's and replacing a few other heavy helpers with there normal html equivalents and writing some actual javascript instead of using too many js helpers really cut down on render time. This is one of the most important things to look at in a rails app that cannot use caching. I have also had some great template speed ups from using Stephan Kaes excellent Template Optimizer[1]. Also if you have controller or view helper, or model methods that will get called more then once *during the same request* then use the ||= operator to cache the results like this: def get_something @something ||= big_calculation_to_get_something end This way only the first call to the method will actually do the computation and all the other calls withint the same request will use the cached data in the instance var. Of course you must look at the db too if you are using heavy queries. The development logs can help you see how chatty you are being with the database. Sometimes your view need to render every hit but if you can cache heavy db queries in memory even every 5 or 10 minutes can make a huge difference. Look into memcached or a custom drb caching solution for this depending on how heavily it will be used. Favor memcached if it will play a big role in your app. -Ezra From ezmobius at gmail.com Fri Sep 1 12:12:06 2006 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Fri, 1 Sep 2006 09:12:06 -0700 Subject: [Mongrel] Application performance In-Reply-To: <48A76CF9-8886-4DF4-B147-4991FEA79C17@brainspl.at> References: <48A76CF9-8886-4DF4-B147-4991FEA79C17@brainspl.at> Message-ID: <6D9432AB-9E01-4A85-814D-58F217964A6A@brainspl.at> On Sep 1, 2006, at 8:58 AM, Ezra Zygmuntowicz wrote: > HI~ > > On Sep 1, 2006, at 7:07 AM, Kirk Haines wrote: > >> On 9/1/06, Tim Perrett wrote: >> >>> If im needing to boost performance how might one go about doing it? >> >> 35-38/second can move a lot of traffic, as has been mentioned, so >> long >> as it's 35-38/second for your dynamic traffic, and your static files >> are much, much faster. >> >> However, when you benchmark 35-38 requests per second, how many >> concurrent requests are you handing? Can you get 35-38/second with >> one request at a time, or do you need several concurrent requests to >> get that speed? How long does it take to actually render a page from >> your application, from the time the request goes into Rails to the >> time that it comes out? >> >> That latency can make a big difference in the apparent speed of your >> application, even if your total throughput is good. >> >> As for how to speed up page rendering, is there anything that you >> query from the database that you can cache to avoid db traffic during >> a hit? That can make a very significant difference. It doesn't >> matter if you can render 300 pages per second of plain text if, when >> you do the required db activity, the db bottlenecks you down to >> 10% of >> that. >> >> Within your Ruby itself there are some easy things that can make >> differences. >> >> If you use inject() anywhere, benchmark that usage. inject() can be >> elegant as heck, but it's also often as slow as it is elegant, and it >> tends to create a lot of junk objects that have to be garbage >> collected. It can sometimes be phenomenally slow compared to a >> solution that doesn't use it. >> >> Do you do any string creation, aggregating from smaller pieces? Use >> << instead of +. >> >> In hash lookups with strings, hash dups the key. If you give it a >> frozen string it's faster. If you do a lot of hash lookups this can >> add up. >> >> In general, try to be aware of your frivolous object creation. Ruby >> isn't terribly slow with object creation, but it's still more >> expensive to use a new object than to reuse an old one, especially >> when garbage collection is taken into account. >> >> But before you spend too much time on any of that, take a look at >> what >> you can do to cache your database transactions in order to minimize >> them. If that is the bottleneck, everything else is a meager drop in >> the bucket. >> >> >> Kirk Haines > > > Very good stuff Kirk. I'll mention a few things from my attempts to > speed up rails applications. When you look at a rails app like the > one being discussed you need to realize that the view templates are > getting rendered every hit if there is no caching. How heavy are your > views? Using a ton of link_to and all the other helpers is very nice > to work with but can kill your performance. I am workign on an app > with almost no caching and tons of ajax. After benchmarking it turned > out that rendering the view templates was actually taking around 60% > of the total time rails spent servicing a request. By switching a > number of link_to's into 's and replacing a few other heavy > helpers with there normal html equivalents and writing some actual > javascript instead of using too many js helpers really cut down on > render time. This is one of the most important things to look at in a > rails app that cannot use caching. I have also had some great > template speed ups from using Stephan Kaes excellent Template > Optimizer[1]. Gah! Sorry forgot to include a link in the last email: [1] http://railsexpress.de/blog/articles/2006/08/15/rails-template- optimizer-beta-test#comments -Ezra From zedshaw at zedshaw.com Fri Sep 1 17:38:06 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 01 Sep 2006 14:38:06 -0700 Subject: [Mongrel] Configuring Mongrel logging In-Reply-To: <002701c6cdac$80390f90$5f01a8c0@paullaptop> References: <002701c6cdac$80390f90$5f01a8c0@paullaptop> Message-ID: <1157146686.6146.9.camel@localhost.localdomain> On Fri, 2006-09-01 at 10:53 +0100, Paul Butcher wrote: > Is there any way to configure Mongrel's logging? Specifically, I'd like to > get it to output to syslog. Our Rails apps already do this (via > SyslogLogger) - is there any way to persuade Mongrel to do the same? No, sorry Paul. Mongrel's logging is super lo-fi, just intended for errors only. In normal functioning it usually doesn't output anything but simple start-up messages and log messages for when there's a crash. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jjhogue at sbcglobal.net Fri Sep 1 17:58:17 2006 From: jjhogue at sbcglobal.net (Jim Hogue) Date: Fri, 1 Sep 2006 17:58:17 -0400 Subject: [Mongrel] Mongrel without rails Message-ID: <009b01c6ce11$bb347160$0400a8c0@DEN2> Can I run mongrel without rails? - Jim From matt at eastmedia.com Fri Sep 1 18:10:46 2006 From: matt at eastmedia.com (Matt Pelletier) Date: Fri, 1 Sep 2006 18:10:46 -0400 Subject: [Mongrel] Mongrel without rails In-Reply-To: <009b01c6ce11$bb347160$0400a8c0@DEN2> References: <009b01c6ce11$bb347160$0400a8c0@DEN2> Message-ID: <9239189A-FB3B-41D2-97A3-C68B23E4EC07@eastmedia.com> Hi Jim, On Sep 1, 2006, at 5:58 PM, Jim Hogue wrote: > Can I run mongrel without rails? > Yes, since it's just Ruby you can run any Ruby code. Depending on what you're doing you can write a handler to have Mongrel load your app and send it the request. It runs with Og+Nitro and Camping in addition to Rails. You should check out the Ruby code of Mongrel to see how Nitro, Camping and Rails are loaded. Matt > - Jim > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > =================== Matt Pelletier EastMedia t. 212-921-8413 x3# m. 917-902-2525 f. 212-239-4114 w. www.eastmedia.com From zedshaw at zedshaw.com Fri Sep 1 18:22:53 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 01 Sep 2006 15:22:53 -0700 Subject: [Mongrel] Setup with Apache 2.2 proxy balancer : timeout during uploads In-Reply-To: <44F82ACF.1080202@lan-attack.ch> References: <44F49956.8080308@lan-attack.ch> <44F6E02B.4050003@lan-attack.ch> <1157061520.7167.8.camel@localhost.localdomain> <44F82ACF.1080202@lan-attack.ch> Message-ID: <1157149373.6146.12.camel@localhost.localdomain> On Fri, 2006-09-01 at 14:42 +0200, Philippe Jayet wrote: > > Yes, Mongrel processes the full request, including uploaded body before > > calling rails (and locking it). If the request is large then it also > > streams the result to a tmpfile in order to not use up ram. > > You're doing an amazing job Zed :) > Thanks! > > The response Rails generates is placed into an internal buffer and then > > when Rails is done Mongrel unlocks rails and spends the rest of it's > > time sending back the response. This is necessary so that Rails can be > > locked for the shortest amount of time. > > How does it interact with send_file and send_data? Which method is the > best to use to serve files of serveral MB? Ah, yes, problem with those is that they're run inside Rails, so they're done during the lock and streamed out into the buffer mongrel hands to rails. Not a good combo. You're actually *best* off using mod_xsendfile from apache, which lets you write the giganto data to a file and then put an "X-Sendfile" header in the response pointing at this file. Apache will then pick the file up as the response body and shoot it to the client without bothering you. Lighttpd also has this in the latest (unstable) version. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Fri Sep 1 18:25:44 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 01 Sep 2006 15:25:44 -0700 Subject: [Mongrel] Making Mongrel play well with Monit In-Reply-To: References: Message-ID: <1157149544.6146.15.camel@localhost.localdomain> On Fri, 2006-09-01 at 19:54 +0530, Vishnu Gopal wrote: > Hi! > > I'm aware this is a more 'monit question', but Zed had suggested on > the list sometime back that we do monitoring this way. It's definitely your path, but you can get around it by simply running the mongrel_rails script with ruby directly: ruby /home/something/bin/mongrel_rails ... Since ruby should be in your path and is a known executable. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Fri Sep 1 18:37:30 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 01 Sep 2006 15:37:30 -0700 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: References: Message-ID: <1157150250.6146.20.camel@localhost.localdomain> On Fri, 2006-09-01 at 17:36 +0530, hemant wrote: > > In environment.rb file, I initialize a connection to some data vending > servers, through TCP sockets. > > As i know, mongrel serves requests on new threads, so what happens to > this global variable that is shared among the threads.Is there a > possiblity that, problem is here? > I mean, lets say a thread is using this global variable for fetching > data for protocol code xxx and same time another thread requests for > protocol code yyy. My connection class, which is basically a proxy to > these data vending servers, may not be thread safe.If this is the > problem, then can anybody suggest better approach of making single > connection to data vending servers, without using shared global > variables. Well, Mongrel locks Rails with a Sync (Mutex caused leaks on some platforms) so there should be only one user of your global variable at any one time. Also, the threads aren't using your global after the request is finished and the lock is released since rails is done dispatching. But, if you're running multiple Mongrels, then you'll get concurrent access to your backend server. Unless that server is written to support concurrent access then you'll have these kinds of issues. BTW, have you considered just using DRb? It's really fast, very easy to use, and it would probably solve many of these issues. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Fri Sep 1 18:55:10 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 01 Sep 2006 15:55:10 -0700 Subject: [Mongrel] Application performance In-Reply-To: References: Message-ID: <1157151310.6146.36.camel@localhost.localdomain> On Fri, 2006-09-01 at 12:54 +0100, Tim Perrett wrote: > Hey all > > Im working on improving the speed of my application. Ive taken on board > everything that has been said on this forum so far, im using httperf to > benchmark and try to improve performance. However, I have some question > marks over how best to go about improving performance in certain areas.... > > With no caching or such like deployed the application runs at an rather slow > 35 - 38 req/s. A static file from the server runs at 872 req/s - so im > rather far behind that. A basic rails app with render text runs at around > 200 req/s. So realistically there is a lot more tuning to be done to get it > to a decent level. Im guessing it changes from app to app but if I aim to > get near 100 req/s that would improve performance to the point of being much > quicker for users? > First, 35-38 isn't that bad. If you've already tried tuning it and this is the best you get then you're probably the tuning density of the app. Only a redesign or more hardware will really make it faster. In other words, you have to move from focusing on little stuff and now look at big stuff: design, deployment, load balancers, architecture, etc. However, have you asked the users? It might be that 35-38 is just fine. It might be that you'll never make it fast enough. What you have to do is get an idea of people's feeling of the speed of the app, and then see what you can do to just make them *think* it's faster. This gets into more messing with human perception than measuring raw performance metrics, but it's also a very effective way of making things "faster" without changing much about your app. A lot of this approach involves getting user feedback, coming up with ways you think will improve their impressions, doing the changes and measuring them, then going back for more feedback. You'll probably stumble on a few simple little changes that will make things seem tons faster. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From gethemant at gmail.com Fri Sep 1 19:37:27 2006 From: gethemant at gmail.com (hemant) Date: Sat, 2 Sep 2006 05:07:27 +0530 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: <1157150250.6146.20.camel@localhost.localdomain> References: <1157150250.6146.20.camel@localhost.localdomain> Message-ID: > > Well, Mongrel locks Rails with a Sync (Mutex caused leaks on some > platforms) so there should be only one user of your global variable at > any one time. Also, the threads aren't using your global after the > request is finished and the lock is released since rails is done > dispatching. > > But, if you're running multiple Mongrels, then you'll get concurrent > access to your backend server. Unless that server is written to support > concurrent access then you'll have these kinds of issues. > > BTW, have you considered just using DRb? It's really fast, very easy to > use, and it would probably solve many of these issues. > > > -- > Zed A. Shaw > So, can't be a issue with my ConnectionClass, right? Basically this UNIXSocket that i connect(sorry for confusion, its actually a UNIXSocket ) , is a proxy between actual data vending servers and rails.Itserves multiple clients(not only rails client, other clients connect to it using TCPSockets) and is written to support multiple concurrent connections. But if I can confirm that there is no issue, with rails connections, then we can inform the other team(i am not author of this proxy server), that please have a look at your code, and see if its thread safe. We have been initially using DRb, but there was a issue with connection pooling.Besides, fetching data in real time from data vending servers was costly, hence this proxy does caching and all that stuff. As per my understanding, the proxy is written like, for each connection it will create a new thread, and a new thread for putting the data to other data vending servers and another thread for receiving the response and sending back to all the connected clients.It attaches unique ids to each request, to make sure that, no data mis-match occurs. But if it would have been written with druby, then it would be a little difficult for other clients to connect. Thanks for help Zed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060902/3f7d390c/attachment.html From luislavena at gmail.com Fri Sep 1 19:50:16 2006 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 1 Sep 2006 20:50:16 -0300 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: References: <1157150250.6146.20.camel@localhost.localdomain> Message-ID: <71166b3b0609011650h748675car263a098dbff3000d@mail.gmail.com> On 9/1/06, hemant wrote: [snip] > So, can't be a issue with my ConnectionClass, right? > > Basically this UNIXSocket that i connect(sorry for confusion, its actually a > UNIXSocket ) , is a proxy between actual data vending servers and rails.It > serves multiple clients(not only rails client, other clients connect to it > using TCPSockets) and is written to support multiple concurrent connections. > But if I can confirm that there is no issue, with rails connections, then we > can inform the other team(i am not author of this proxy server), that please > have a look at your code, and see if its thread safe. UNIXSocket is like file sockets, right? that means One process accessing it could put garbage IF other process jump into the socket. Someone correct me if I'm wrong, but multiple mongrel running from the same file socket will produce the behavior you're getting (misplaced stuff in the replies). > > We have been initially using DRb, but there was a issue with connection > pooling.Besides, fetching data in real time from data vending servers was > costly, hence this proxy does caching and all that stuff. As per my > understanding, the proxy is written like, for each connection it will create > a new thread, and a new thread for putting the data to other data vending > servers and another thread for receiving the response and sending back to > all the connected clients.It attaches unique ids to each request, to make > sure that, no data mis-match occurs. A pool of connections (one implemented around multiuser protocols... TCPSocket) is my suggestion. If your ConnectionClass could connect to your vending server using a TCP Socket, it will work fine under multiple mongrels. > > But if it would have been written with druby, then it would be a little > difficult for other clients to connect. > > Thanks for help Zed. > -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From gethemant at gmail.com Fri Sep 1 22:32:14 2006 From: gethemant at gmail.com (hemant) Date: Sat, 2 Sep 2006 08:02:14 +0530 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: <71166b3b0609011650h748675car263a098dbff3000d@mail.gmail.com> References: <1157150250.6146.20.camel@localhost.localdomain> <71166b3b0609011650h748675car263a098dbff3000d@mail.gmail.com> Message-ID: We initially chose UNIXSocket over TCPSockets, because of performance reasons. As it turns out, its not so scalabale..so we may scrap it. On 9/2/06, Luis Lavena wrote: > > On 9/1/06, hemant wrote: > [snip] > > So, can't be a issue with my ConnectionClass, right? > > > > Basically this UNIXSocket that i connect(sorry for confusion, its > actually a > > UNIXSocket ) , is a proxy between actual data vending servers and > rails.It > > serves multiple clients(not only rails client, other clients connect to > it > > using TCPSockets) and is written to support multiple concurrent > connections. > > But if I can confirm that there is no issue, with rails connections, > then we > > can inform the other team(i am not author of this proxy server), that > please > > have a look at your code, and see if its thread safe. > > UNIXSocket is like file sockets, right? that means One process > accessing it could put garbage IF other process jump into the socket. > > Someone correct me if I'm wrong, but multiple mongrel running from the > same file socket will produce the behavior you're getting (misplaced > stuff in the replies). > > > > > We have been initially using DRb, but there was a issue with connection > > pooling.Besides, fetching data in real time from data vending servers > was > > costly, hence this proxy does caching and all that stuff. As per my > > understanding, the proxy is written like, for each connection it will > create > > a new thread, and a new thread for putting the data to other data > vending > > servers and another thread for receiving the response and sending back > to > > all the connected clients.It attaches unique ids to each request, to > make > > sure that, no data mis-match occurs. > > A pool of connections (one implemented around multiuser protocols... > TCPSocket) is my suggestion. > > If your ConnectionClass could connect to your vending server using a > TCP Socket, it will work fine under multiple mongrels. > > > > > But if it would have been written with druby, then it would be a little > > difficult for other clients to connect. > > > > Thanks for help Zed. > > > > -- > Luis Lavena > Multimedia systems > - > Leaders are made, they are not born. They are made by hard effort, > which is the price which all of us must pay to achieve any goal that > is worthwhile. > Vince Lombardi > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060902/0d595bbd/attachment.html From kigsteronline at mac.com Fri Sep 1 23:41:28 2006 From: kigsteronline at mac.com (kigsteronline at mac.com) Date: Fri, 1 Sep 2006 20:41:28 -0700 Subject: [Mongrel] Another site running mongrel went live In-Reply-To: References: <1157150250.6146.20.camel@localhost.localdomain> <71166b3b0609011650h748675car263a098dbff3000d@mail.gmail.com> Message-ID: Wanted to throw out there that we just launched our Rails application running on Apache 2.2/Mongrel. We've been working on it for a few months and it's finally up and running - check out http://www.blurb.com/ Blurb allows people to create, publish and sell professionally looking books online, although book creation software is not currently web-based, and is a client download for Windows/Mac. Special thanks to Zed and the rest of the mongrel and cluster teams for providing such a great rails application server. K From luislavena at gmail.com Sat Sep 2 02:34:29 2006 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 2 Sep 2006 03:34:29 -0300 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: References: <1157150250.6146.20.camel@localhost.localdomain> <71166b3b0609011650h748675car263a098dbff3000d@mail.gmail.com> Message-ID: <71166b3b0609012334x4e28dbbfm8cdafaa31faa843@mail.gmail.com> On 9/1/06, hemant wrote: > > We initially chose UNIXSocket over TCPSockets, because of performance > reasons. > > As it turns out, its not so scalabale..so we may scrap it. Ok, is your UNIXServer implemented in a multithread fashion? (so it could hadle multiple clients to connect). how its coded? Like this: require 'socket' SOCKET = "/tmp/sample" server_thread = Thread.start do # run server in a thread sock = UNIXServer.open(SOCKET) s1 = sock.accept p s1.recvfrom(124) end client = UNIXSocket.open(SOCKET) client.send("hello", 0) client.close server_thread.join I compared unix sockets to windows pipes... which is wrong, my mistake. Have you tried connect to ruby clients in the same machine to the running socket server? If that works, then your problem could be... anything ;-) (just kidding) -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From gethemant at gmail.com Sat Sep 2 07:30:43 2006 From: gethemant at gmail.com (hemant) Date: Sat, 2 Sep 2006 17:00:43 +0530 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: <71166b3b0609012334x4e28dbbfm8cdafaa31faa843@mail.gmail.com> References: <1157150250.6146.20.camel@localhost.localdomain> <71166b3b0609011650h748675car263a098dbff3000d@mail.gmail.com> <71166b3b0609012334x4e28dbbfm8cdafaa31faa843@mail.gmail.com> Message-ID: Yes...its a multithreaded and supposed to server request flawlessly. BTW, as a quick check...i wrote a ruby program to fetch data for some 10000 iterations and and append it to a CSV file...and didn't get a single data mangling error. Next step, I will try 100 simultaneous threads, fetching the data and see if there is a mis-match. On 9/2/06, Luis Lavena wrote: > > On 9/1/06, hemant wrote: > > > > We initially chose UNIXSocket over TCPSockets, because of performance > > reasons. > > > > As it turns out, its not so scalabale..so we may scrap it. > > Ok, is your UNIXServer implemented in a multithread fashion? (so it > could hadle multiple clients to connect). > > how its coded? > > Like this: > > require 'socket' > SOCKET = "/tmp/sample" > server_thread = Thread.start do # run server in a thread > sock = UNIXServer.open(SOCKET) > s1 = sock.accept > p s1.recvfrom(124) > end > > client = UNIXSocket.open(SOCKET) > client.send("hello", 0) > client.close > server_thread.join > > I compared unix sockets to windows pipes... which is wrong, my mistake. > > Have you tried connect to ruby clients in the same machine to the > running socket server? > > If that works, then your problem could be... anything ;-) (just kidding) > > -- > Luis Lavena > Multimedia systems > - > Leaders are made, they are not born. They are made by hard effort, > which is the price which all of us must pay to achieve any goal that > is worthwhile. > Vince Lombardi > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060902/44a94857/attachment.html From zedshaw at zedshaw.com Sat Sep 2 08:16:14 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sat, 02 Sep 2006 05:16:14 -0700 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: References: <1157150250.6146.20.camel@localhost.localdomain> <71166b3b0609011650h748675car263a098dbff3000d@mail.gmail.com> <71166b3b0609012334x4e28dbbfm8cdafaa31faa843@mail.gmail.com> Message-ID: <1157199374.9315.0.camel@localhost.localdomain> On Sat, 2006-09-02 at 17:00 +0530, hemant wrote: > Yes...its a multithreaded and supposed to server request flawlessly. > > BTW, as a quick check...i wrote a ruby program to fetch data for some > 10000 iterations and and append it to a CSV file...and didn't get a > single data mangling error. > > Next step, I will try 100 simultaneous threads, fetching the data and > see if there is a mis-match. And randomize it. Ruby's threads work fairly predictably so without a random short think time to mix things up you won't get good results. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From kevwil at gmail.com Sat Sep 2 10:26:47 2006 From: kevwil at gmail.com (Kevin Williams) Date: Sat, 2 Sep 2006 08:26:47 -0600 Subject: [Mongrel] custom error handling Message-ID: <683a886f0609020726u77cb40a3jc6d2eb9b87b8c78e@mail.gmail.com> Please forgive me if this is a stupid question. If it has been answered already, please point me to the answer, as my searching has been fruitless. How can I programatically handle 404s and 500s when using Mongrel? I've read about using a proxy server config (.htaccess for example) to render an ErrorDocument rather than whatever comes from Rails, but I need something different. I would like to send an email on 500 errors, and log 40x errors. It would be nice to do this within my app code. I ask here simply because everything I've found has dealt with either plain html pages or FCGI. Thanks in advance! -- Cheers, Kevin "Any sufficiently advanced technology is indistinguishable from Magic." - Arthur C. Clarke From paul at paulbutcher.com Sat Sep 2 12:49:20 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Sat, 2 Sep 2006 17:49:20 +0100 Subject: [Mongrel] Configuring Mongrel logging In-Reply-To: <1157146686.6146.9.camel@localhost.localdomain> Message-ID: <00af01c6ceaf$bd13d4f0$7301a8c0@paullaptop> > No, sorry Paul. Mongrel's logging is super lo-fi, just intended for > errors only. In normal functioning it usually doesn't output anything > but simple start-up messages and log messages for when there's a crash. Cheers Zed, Actually, it's crashes in particular that we're interested in. We have a system set up which examines anything sent to syslog and rings all the alarm bells if anything is logged with more than a certain severity. Ah well - I'm sure that we'll find some other way to achieve this with Mongrel. Thanks, -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From jeroen at supercool.nl Sun Sep 3 10:12:38 2006 From: jeroen at supercool.nl (Jeroen Houben) Date: Sun, 03 Sep 2006 16:12:38 +0200 Subject: [Mongrel] first request always fails Message-ID: <44FAE2D6.2010602@supercool.nl> Hi, Whenever I restart mongrel on my production server, the first request in my browser always fails, I get this error: Processing Base#index (for 83.xx.xx.xx at 2006-09-03 16:08:47) [GET] Session ID: f1918346d193e19a70c3230286e5ce1a Parameters: {} TypeError (superclass mismatch for class Stats): /app/models/stats.rb:1 stats.rb:1 just contains a normal A/R line: class Stats < ActiveRecord::Base Strange thing is that when I reload the page in my browser things work and every subsequent request works. Until I restart mongrel, the same happens again. I'm using postgresql so I'm wondering if something's going wrong on the initial connect. Any ideas?? Jeroen From zedshaw at zedshaw.com Sun Sep 3 10:24:06 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 07:24:06 -0700 Subject: [Mongrel] first request always fails In-Reply-To: <44FAE2D6.2010602@supercool.nl> References: <44FAE2D6.2010602@supercool.nl> Message-ID: <1157293446.6020.8.camel@localhost.localdomain> On Sun, 2006-09-03 at 16:12 +0200, Jeroen Houben wrote: > Hi, > > Whenever I restart mongrel on my production server, the first request in > my browser always fails, I get this error: > > Processing Base#index (for 83.xx.xx.xx at 2006-09-03 16:08:47) [GET] > Session ID: f1918346d193e19a70c3230286e5ce1a > Parameters: {} > > > TypeError (superclass mismatch for class Stats): > /app/models/stats.rb:1 Ah, there's a Stats class already in Mongrel but it's not in the mongrel module. I'll move that over and see if it breaks anyone. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jeroen at supercool.nl Sun Sep 3 10:34:39 2006 From: jeroen at supercool.nl (Jeroen Houben) Date: Sun, 03 Sep 2006 16:34:39 +0200 Subject: [Mongrel] first request always fails In-Reply-To: <1157293446.6020.8.camel@localhost.localdomain> References: <44FAE2D6.2010602@supercool.nl> <1157293446.6020.8.camel@localhost.localdomain> Message-ID: <44FAE7FF.3050401@supercool.nl> Zed Shaw wrote: > On Sun, 2006-09-03 at 16:12 +0200, Jeroen Houben wrote: >> Hi, >> >> Whenever I restart mongrel on my production server, the first request in >> my browser always fails, I get this error: >> >> Processing Base#index (for 83.xx.xx.xx at 2006-09-03 16:08:47) [GET] >> Session ID: f1918346d193e19a70c3230286e5ce1a >> Parameters: {} >> >> >> TypeError (superclass mismatch for class Stats): >> /app/models/stats.rb:1 > > Ah, there's a Stats class already in Mongrel but it's not in the mongrel > module. I'll move that over and see if it breaks anyone. > > Aha. Could this also be the cause of my other problem where my custom ENV['site'] value does not get picked up by environment.rb? http://www.ruby-forum.com/topic/79765#133114 ENV['site'] *is* available in my views, controllers etc but doing: RAILS_DEFAULT_LOGGER.warn("ENV: #{ENV.inspect}") in environment.rb shows no sign of ENV['site'] Jeroen From zedshaw at zedshaw.com Sun Sep 3 11:28:47 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 08:28:47 -0700 Subject: [Mongrel] first request always fails In-Reply-To: <44FAE7FF.3050401@supercool.nl> References: <44FAE2D6.2010602@supercool.nl> <1157293446.6020.8.camel@localhost.localdomain> <44FAE7FF.3050401@supercool.nl> Message-ID: <1157297327.6020.16.camel@localhost.localdomain> On Sun, 2006-09-03 at 16:34 +0200, Jeroen Houben wrote: > Zed Shaw wrote: > > On Sun, 2006-09-03 at 16:12 +0200, Jeroen Houben wrote: > Aha. Could this also be the cause of my other problem where my custom > ENV['site'] value does not get picked up by environment.rb? > http://www.ruby-forum.com/topic/79765#133114 > > ENV['site'] *is* available in my views, controllers etc but doing: > > RAILS_DEFAULT_LOGGER.warn("ENV: #{ENV.inspect}") > > in environment.rb shows no sign of ENV['site'] Nope, the only reference to ENV in mongrel is in rails.rb where I set it for production. Otherwise, that's a Ruby constant so you'd see big complaints if I messed with that (or anyone did). But, why are you using ENV? You could just use any constant you want in environment.rb. Try making a SITE_CONFIG = {'site' => 'stuff.com'} and see if that works instead. In truth, getting site config values from ENV is kind of a no-no since you can't trust ENV. It's the reason a lot of programs clear ENV before starting other programs. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jeroen at supercool.nl Sun Sep 3 11:45:52 2006 From: jeroen at supercool.nl (Jeroen Houben) Date: Sun, 03 Sep 2006 17:45:52 +0200 Subject: [Mongrel] first request always fails In-Reply-To: <1157297327.6020.16.camel@localhost.localdomain> References: <44FAE2D6.2010602@supercool.nl> <1157293446.6020.8.camel@localhost.localdomain> <44FAE7FF.3050401@supercool.nl> <1157297327.6020.16.camel@localhost.localdomain> Message-ID: <44FAF8B0.7050001@supercool.nl> Zed Shaw wrote: > But, why are you using ENV? You could just use any constant you want in > environment.rb. Try making a SITE_CONFIG = {'site' => 'stuff.com'} and > see if that works instead. The reason I'm using it is because I'm running multiple sites from one rails app. I'm trying to pass some sort of variable to each mongrel upon startup to indicate which subdomain (and thus which client) each mongrel belongs to. I'm sure there is a better and DRYer way to so this, but I haven't found it yet. Anyway, then in environment.rb I do something like this: # Set the SITE constant. Defaults to 'demo' SITE = ENV['site ? ENV['site'] : 'demo ## initialize site specific information globals_file = File.join(File.dirname(__FILE__), "../sites/#{SITE}/config/Globals.rb") if File.exist?(globals_file) require globals_file else ... The SITE constant is also used in database.yml > In truth, getting site config values from ENV is kind of a no-no since > you can't trust ENV. It's the reason a lot of programs clear ENV before > starting other programs. > Yeah I figured it wasn't the best way, but it worked for my lighty+fastcgi setup so I never really thought about it anymore. Thanks for replying so quickly btw! Jeroen From zedshaw at zedshaw.com Sun Sep 3 11:54:39 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 08:54:39 -0700 Subject: [Mongrel] first request always fails In-Reply-To: <44FAF8B0.7050001@supercool.nl> References: <44FAE2D6.2010602@supercool.nl> <1157293446.6020.8.camel@localhost.localdomain> <44FAE7FF.3050401@supercool.nl> <1157297327.6020.16.camel@localhost.localdomain> <44FAF8B0.7050001@supercool.nl> Message-ID: <1157298879.6020.24.camel@localhost.localdomain> On Sun, 2006-09-03 at 17:45 +0200, Jeroen Houben wrote: > Zed Shaw wrote: > > But, why are you using ENV? You could just use any constant you want in > > environment.rb. Try making a SITE_CONFIG = {'site' => 'stuff.com'} and > > see if that works instead. > > The reason I'm using it is because I'm running multiple sites from one > rails app. I'm trying to pass some sort of variable to each mongrel upon > startup to indicate which subdomain (and thus which client) each > mongrel belongs to. I'm sure there is a better and DRYer way to so this, > but I haven't found it yet. Ok, why not an environment for each site? Just like production.rb or development.rb, but demo.rb, mysite.rb. Then, you just pass in -e demo.rb. People do this quite frequently, only catch is to make sure that you haven't relied on the environment setting for other stuff, but even that you could change to "production" manually inside the demo.rb. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Sun Sep 3 12:18:06 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 09:18:06 -0700 Subject: [Mongrel] Recommentation: Sessions and PStore Message-ID: <1157300286.6020.50.camel@localhost.localdomain> Morning Folks, As most of you know there were a few people who had the following three bugs: * CLOSE_WAIT: Lots of sockets in CLOSE_WAIT state. * 99% CPU: Mongrel's getting "stuck" pegged at 99% CPU. * LEAK: Memory leak. I've successfully fixed these bugs or attributed them to one main cause: pstore. First, the memory leak was because of a bug in how the GC in Ruby was collecting threads after they used a Mutex. Don't ask me why, but switching to Sync fixed it. Problem is, this also causes the leak on Win32. Still working on that problem. Now for the recommendations: 1) DON'T USE PSTORE AS A SESSION STORE! All of the people who had Mongrel processes going crazy, blocking, locking, or just generally doing bad things had a pstore as their session storage option. What happens is the pstore isn't that great when multiple processes access it, and if one Mongrel has problems pulling an object from the pstore then it'll explode. Use the file store when you develop, and use the database or memcached store in production. You should also be looking for other ways processes are sharing resources when they lock up or do weird things. Try running with just one process, and if you don't have any problems then it's a resource locking problem (most likely). 2) DON'T STORE COMPLEX OBJECTS IN THE SESSION! This especially goes for you Java people who think the session store is a temporary database. The session really only works for simple types like integers, strings, etc. You *must* follow the mantra of "Share Nothing" and either store everything in the database or use form fields and GET parameters to make it stateless. As I've said repeatedly, "If rails-core don't do it, you don't do it." Rails-core does not do this. You don't do it. 3) USE THE USR1 LOGGING! Every person who had a problem with Mongrel processes getting stuck could have used the new USR1 logging to quickly find out what Rails action was blocking the process. Once I got a good USR1 log it was trivial to see a message stating that 981 threads were waiting for one Rails action. Once I pointed this out, they went back and figured out what the problem was. Use "killall -USR1 mongrel_rails" to turn this on temporarily, and Mongrel will log the numbers of threads waiting for each request and which are remaining to be processed by Mongrel. It's very handy. Hitting the mongrels with USR1 again turns it off. It's also pretty fast so you could leave it on all the time and not see a big performance hit. 4) YOUR RAILS CODE SUCKS! I hate to say it folks, and I'll gladly help people when they've got a problem, but please check your Rails code first, and assume it's broken. Lots and lots and lots and lots of sites are running high traffic Mongrel installs without any problems. If you have a problem, then you've got something different. I know, you're absolutely perfect and there's nothing you're doing strange, but really look. In all the cases mentioned above they were also doing something weird. Things to look for: * Using extensions to libraries you didn't write. If you have a library that you bought and then wrapped with Ruby's extensions, then chances are it's *not* designed for multi-threaded Ruby action. Move this library to a sequentially run DRb process shared by all your Mongrel processes. * Trying to resolve hosts against broken DNS. Many people have slow rails actions because they're doing tons of DNS resolving of hosts. Make sure your internal DNS is fast, reliable and consider using dnsmasq running locally to cache the results. Main problem is Ruby's resolving blocks the process. * Use pstore as the session store, so probably using pstore for nearly anything is bad. * Using your own custom network protocols. If you just wrote it then it's broken. #1, #2, and #3 rule of programming. It's not Mongrel. * Using the mysql.rb instead of installing the actual mysql compiled gem. The mysql.rb is just for development, and it sucks horribly. Thanks for your time folks, and keep coming with those bugs. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Sun Sep 3 12:24:37 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 09:24:37 -0700 Subject: [Mongrel] [ANN] Documentation Day! Message-ID: <1157300677.6020.57.camel@localhost.localdomain> I'm spending today writing documentation. I'll be updating quite a few documents, doing some edits, and adding some user contributed docs. If anyone has documentation suggestions, FAQ questions they'd like included, or things they think are old and stale, then let me know. Swing by the Lingr room: http://www.lingr.com/room/3yXhqKbfPy8 And drop me a line if you want to contribute something as well. Documents in the queue for editing today are: * FAQ -- Gonna clean out some old stuff and add a bunch of common questions (suggestions welcome). * FASQ -- I think I need to include some stupid questions people ask as well. :-) * Debian -- Finally got Chris McGrath's debian documentation up. http://mongrel.rubyforge.org/docs/debian-sarge.html * Apache -- Philip Hallstrom donate some initial Apache documentation too. http://mongrel.rubyforge.org/docs/apache.html * Adoptions -- I'm gonna add in success stories I haven't put in yet, and if anyone has some more let me know. * Mongrels -- Got a few new dogs and owners to put on. And that should get things going for the 0.3.13.4 release. If I can find time then I'll update the plugins documentation to show how to write handlers and such. Thanks! -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jeroen at supercool.nl Sun Sep 3 12:25:28 2006 From: jeroen at supercool.nl (Jeroen Houben) Date: Sun, 03 Sep 2006 18:25:28 +0200 Subject: [Mongrel] first request always fails In-Reply-To: <1157298879.6020.24.camel@localhost.localdomain> References: <44FAE2D6.2010602@supercool.nl> <1157293446.6020.8.camel@localhost.localdomain> <44FAE7FF.3050401@supercool.nl> <1157297327.6020.16.camel@localhost.localdomain> <44FAF8B0.7050001@supercool.nl> <1157298879.6020.24.camel@localhost.localdomain> Message-ID: <44FB01F8.9010208@supercool.nl> Zed Shaw wrote: > On Sun, 2006-09-03 at 17:45 +0200, Jeroen Houben wrote: >> Zed Shaw wrote: >>> But, why are you using ENV? You could just use any constant you want in >>> environment.rb. Try making a SITE_CONFIG = {'site' => 'stuff.com'} and >>> see if that works instead. >> The reason I'm using it is because I'm running multiple sites from one >> rails app. I'm trying to pass some sort of variable to each mongrel upon >> startup to indicate which subdomain (and thus which client) each >> mongrel belongs to. I'm sure there is a better and DRYer way to so this, >> but I haven't found it yet. > > Ok, why not an environment for each site? Just like production.rb or > development.rb, but demo.rb, mysite.rb. Then, you just pass in -e > demo.rb. > > People do this quite frequently, only catch is to make sure that you > haven't relied on the environment setting for other stuff, but even that > you could change to "production" manually inside the demo.rb. > > Interesting. I can't help to feel this is a bit hackish too. But if it works it works I suppose.. So I'm guessing you need individual mongrel_cluster.yml files for each site and then fire up the mongrel_cluster with -C switch. I'll give that a go later tonight. Thanks! Jeroen From wyhaines at gmail.com Sun Sep 3 12:42:15 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Sun, 3 Sep 2006 10:42:15 -0600 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <1157300286.6020.50.camel@localhost.localdomain> References: <1157300286.6020.50.camel@localhost.localdomain> Message-ID: On 9/3/06, Zed Shaw wrote: > First, the memory leak was because of a bug in how the GC in Ruby was > collecting threads after they used a Mutex. Don't ask me why, but > switching to Sync fixed it. Problem is, this also causes the leak on > Win32. Still working on that problem. I still doubt that Mutex itself is the problem here. Sync uses the same algorithm for exclusive locking, and I can run _millions_ of threads through IOWA, which operates similarly to Mutex with regard to how it spawns threads, without any memory leaks, and Mutex gets used with every one of those requests/threads. > All of the people who had Mongrel processes going crazy, blocking, > locking, or just generally doing bad things had a pstore as their > session storage option. What happens is the pstore isn't that great > when multiple processes access it, and if one Mongrel has problems > pulling an object from the pstore then it'll explode. Use the file > store when you develop, and use the database or memcached store in > production. I have had similar misery with PStore. I've been meaning to get it done for a month, but I have a process/threadsafe to-disk persistence library that I will bundle and release separately from IOWA. It provides relatively fast persistence and could be used to store sessions like people use PStore. I'll try to finally get that done today if anyone wants to try it out as a PStore replacement for storing sessions to disk. Kirk Haines From wyhaines at gmail.com Sun Sep 3 12:43:18 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Sun, 3 Sep 2006 10:43:18 -0600 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: References: <1157300286.6020.50.camel@localhost.localdomain> Message-ID: On 9/3/06, Kirk Haines wrote: > I still doubt that Mutex itself is the problem here. Sync uses the > same algorithm for exclusive locking, and I can run _millions_ of > threads through IOWA, which operates similarly to Mutex with regard to which runs similarly to Mongrel.... Sorry for the confusion. Kirk Haines From zedshaw at zedshaw.com Sun Sep 3 13:20:31 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 10:20:31 -0700 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: References: <1157300286.6020.50.camel@localhost.localdomain> Message-ID: <1157304031.10409.0.camel@localhost.localdomain> On Sun, 2006-09-03 at 10:42 -0600, Kirk Haines wrote: > On 9/3/06, Zed Shaw wrote: > > > First, the memory leak was because of a bug in how the GC in Ruby was > > collecting threads after they used a Mutex. Don't ask me why, but > > switching to Sync fixed it. Problem is, this also causes the leak on > > Win32. Still working on that problem. > > I still doubt that Mutex itself is the problem here. Sync uses the > same algorithm for exclusive locking, and I can run _millions_ of > threads through IOWA, which operates similarly to Mutex with regard to > how it spawns threads, without any memory leaks, and Mutex gets used > with every one of those requests/threads. Theorize all you want, but all I know is, use Mutex, process gets killed, use Sync, process stays up. Can't argue with the evidence. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jaredbrown at gmail.com Sun Sep 3 13:40:46 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Sun, 3 Sep 2006 13:40:46 -0400 Subject: [Mongrel] How many mongrel servers should I run in my cluster? Message-ID: The company I work for is launching a new web site tomorrow. News of our launch will be published in major publications throughout the week so I want to make sure we are prepared for the load. Production Environment: HP Proliant server w/ 8GB RAM and dual AMD64 Opterons Memcache is used as the session and fragment store (512MB for it) MySQL is running on a seperate server in the same rack We use the mysql gem for Ruby for greater speed and reliability This server is dedicated to running just this rails app, so how many mongrel servers should I put in the cluster? And how many clusters should I setup? The server needs to survive tens of thousands of page views per hour. -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060903/6ab05bff/attachment.html From jason at joyent.com Sun Sep 3 13:43:26 2006 From: jason at joyent.com (Jason A. Hoffman) Date: Sun, 3 Sep 2006 10:43:26 -0700 Subject: [Mongrel] How many mongrel servers should I run in my cluster? In-Reply-To: References: Message-ID: On Sep 3, 2006, at 10:40 AM, Jared Brown wrote: > The company I work for is launching a new web site tomorrow. > News of our launch will be published in major publications > throughout the week so I want to make sure we are prepared for the > load. > > Production Environment: > HP Proliant server w/ 8GB RAM and dual AMD64 Opterons > Memcache is used as the session and fragment store (512MB for it) > MySQL is running on a seperate server in the same rack > We use the mysql gem for Ruby for greater speed and reliability > This server is dedicated to running just this rails app, so how > many mongrel servers should I put in the cluster? > And how many clusters should I setup? > > The server needs to survive tens of thousands of page views per hour. > What are the mongrels behind? - Jason From wyhaines at gmail.com Sun Sep 3 13:48:43 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Sun, 3 Sep 2006 11:48:43 -0600 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <1157304031.10409.0.camel@localhost.localdomain> References: <1157300286.6020.50.camel@localhost.localdomain> <1157304031.10409.0.camel@localhost.localdomain> Message-ID: On 9/3/06, Zed Shaw wrote: > Theorize all you want, but all I know is, use Mutex, process gets > killed, use Sync, process stays up. Can't argue with the evidence. Sure I can. Your conclusion about Mutex is like the conclusion once drawn about the sun. It comes up in the east and goes down in the west, so the evidence clearly shows that the sun rotates around the earth, right? There is nothing wrong with Mutex. It's an incredibly simple piece of code and can quite clearly be demonstrated not to leak. I'm not arguing with the fact that for some users simply swapping Sync in place of Mutex appears to clear a problem. I'm just arguing with your conclusion that this is because Mutex is broken or because Ruby is leaking memory when it is used. Kirk Haines From zedshaw at zedshaw.com Sun Sep 3 13:53:59 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 10:53:59 -0700 Subject: [Mongrel] How many mongrel servers should I run in my cluster? In-Reply-To: References: Message-ID: <1157306039.10409.4.camel@localhost.localdomain> On Sun, 2006-09-03 at 13:40 -0400, Jared Brown wrote: > The company I work for is launching a new web site tomorrow. > News of our launch will be published in major publications throughout > the week so I want to make sure we are prepared for the load. > Freshly minted docs on that very subject: http://mongrel.rubyforge.org/docs/how_many_mongrels.html And you get a FAQ question too. Let me know how that works for you. BTW, waiting until the day before your deployment to set things up is a really bad idea. You usually want to be doing this quite frequently and practicing doing it from scratch for at least a week before your real deployment. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Sun Sep 3 14:34:00 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 11:34:00 -0700 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: References: <1157300286.6020.50.camel@localhost.localdomain> <1157304031.10409.0.camel@localhost.localdomain> Message-ID: <1157308440.10409.27.camel@localhost.localdomain> On Sun, 2006-09-03 at 11:48 -0600, Kirk Haines wrote: > On 9/3/06, Zed Shaw wrote: > > > Theorize all you want, but all I know is, use Mutex, process gets > > killed, use Sync, process stays up. Can't argue with the evidence. > > Sure I can. Your conclusion about Mutex is like the conclusion once > drawn about the sun. It comes up in the east and goes down in the > west, so the evidence clearly shows that the sun rotates around the > earth, right? > > There is nothing wrong with Mutex. It's an incredibly simple piece of > code and can quite clearly be demonstrated not to leak. > > I'm not arguing with the fact that for some users simply swapping Sync > in place of Mutex appears to clear a problem. I'm just arguing with > your conclusion that this is because Mutex is broken or because Ruby > is leaking memory when it is used. I like you Kirk, so don't take it personally, it's just an incredibly sore spot with me since I've been complaining about this for ages and everyone keeps telling me I'm crazy despite what I demonstrate. But, explain this: http://pastie.caboo.se/10194 vs. http://pastie.caboo.se/10317 First one leaks, second one doesn't (with graphs even). What's worse is the inverse is true on win32. These scripts have no Mongrel code, no Rails code, they're just short Ruby scripts. Now, it's not about users, it's about the two bug reductions that simulate how Mongrel uses processes demonstrating a leak in both 1.8.5 and 1.8.4. And it's insulting that you compare my careful examination of the problem and numerous people's countless investigation into this as nothing more than tribal Sun worship. If anything the Ruby morons (not you) running around ignoring Ruby's problems are the religious fanatics who need to get a grip and fix this crap before guys like me get fed up and run happily to a platform that doesn't suck. It also has nothing to do with the Sun, Ptolemaic Astronomy, Polynesian navigation by dead reckoning, or other stuff you read about in that one speech/essay by Feynman about Cargo Cults. I have evidence, many other people reported the same results in different systems, and I have demonstration scripts. The only evidence other people have produced is to write a different script that doesn't leak, which doesn't fix the script that does leak. Instead, the "garbage collection apologists" insist that it's not Mutex, yet the change log for 1.8.5 says there were bugs in the GC code for Threads. I'm betting that it's not fixed, and that people like you who keep arguing it's not a bug are doing nothing but making it so nobody has to admit three things: 1) Threads suck ass in Ruby. 2) The GC sucks even worse. 3) Combining two forms of suckage makes for ultra suckage. But hey, I've been over this a billion times with tons of people, and all I get in response is that I'm totally wrong because someone else can write a different script that doesn't leak. Yet, this different script doesn't fix the script that does leak given above. It's a never ending truly Ptolemaic cycle of Ruby on Ruby when the real problem is deep in the morass of C code that makes up the wonderful split between Thread GC and "everything else GC". So, sorry Kirk, I'm not full of crap or making this up or anything else you're implying. I have demonstration code, I and others run the code and it happens, I have graphs, statistics, measurements, and demonstrated fixes. Oh no, it's not Ruby, it's me. Meanwhile, I don't even have time to go investigate the problem because I'm trying to get this stuff out so people can do their jobs. I'll leave it to the apologists to argue that everything's just quite alright and start looking for my next platform. I hear Lua likes to fix their virtual machine. Maybe I'll start there. Again, sorry for ranting at you directly, but it really doesn't sit right with me to have my careful measurements compared with ancient psuedo-science. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jaredbrown at gmail.com Sun Sep 3 15:14:46 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Sun, 3 Sep 2006 15:14:46 -0400 Subject: [Mongrel] How many mongrel servers should I run in my cluster? In-Reply-To: <1157306039.10409.4.camel@localhost.localdomain> References: <1157306039.10409.4.camel@localhost.localdomain> Message-ID: Haha, yea tell me about it. Unfortunately this is how things have worked out. BTW: The cluster is load balanced using the mod proxy balancer in Apache 2.2.2 On 9/3/06, Zed Shaw wrote: > > On Sun, 2006-09-03 at 13:40 -0400, Jared Brown wrote: > > The company I work for is launching a new web site tomorrow. > > News of our launch will be published in major publications throughout > > the week so I want to make sure we are prepared for the load. > > > > Freshly minted docs on that very subject: > > http://mongrel.rubyforge.org/docs/how_many_mongrels.html > > And you get a FAQ question too. > > Let me know how that works for you. > > BTW, waiting until the day before your deployment to set things up is a > really bad idea. You usually want to be doing this quite frequently and > practicing doing it from scratch for at least a week before your real > deployment. > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060903/0761a28b/attachment.html From jason at joyent.com Sun Sep 3 15:22:36 2006 From: jason at joyent.com (Jason A. Hoffman) Date: Sun, 3 Sep 2006 12:22:36 -0700 Subject: [Mongrel] How many mongrel servers should I run in my cluster? In-Reply-To: References: <1157306039.10409.4.camel@localhost.localdomain> Message-ID: <03AAE299-4CD7-446D-8820-F07166CBC042@joyent.com> So you'll be limited by what Apache will put through. Just remember too that if you're not CPU or memory bound yet, or doing as much database as possible, you can always put in more apache's and do poor man's load balancing across those with DNS. - J On Sep 3, 2006, at 12:14 PM, Jared Brown wrote: > Haha, yea tell me about it. > Unfortunately this is how things have worked out. > > BTW: The cluster is load balanced using the mod proxy balancer in > Apache 2.2.2 > > > On 9/3/06, Zed Shaw wrote: > On Sun, 2006-09-03 at 13:40 -0400, Jared Brown wrote: > > The company I work for is launching a new web site tomorrow. > > News of our launch will be published in major publications > throughout > > the week so I want to make sure we are prepared for the load. > > > > Freshly minted docs on that very subject: > > http://mongrel.rubyforge.org/docs/how_many_mongrels.html > > And you get a FAQ question too. > > Let me know how that works for you. > > BTW, waiting until the day before your deployment to set things up > is a > really bad idea. You usually want to be doing this quite > frequently and > practicing doing it from scratch for at least a week before your real > deployment. > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > -- > Jared Brown > jaredbrown at gmail.com > (765) 409-0875 > 7001 Central Ave > Indianapolis, IN 46220 > _______________________________________________ > 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/20060903/f540ffdc/attachment.html From zedshaw at zedshaw.com Sun Sep 3 15:34:34 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 12:34:34 -0700 Subject: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- Docs and more Docs Message-ID: <1157312074.10409.40.camel@localhost.localdomain> Hi Everyone, Just want to get out another ping on the Mongrel pre-release saga. I've updated a bunch of the documentation to include documents people have donated and to beef up the FAQ for most of the questions people have asked over the past month. INSTALL gem install mongrel --source=http://mongrel.rubyforge.org/releases/ CHANGES * Fixed memory leak by switching to Sync rather than Mutex (please don't argue with me about this not being fixed unless you run Mongrel and Rails and need my help). * Slight change so that if a file is small then it'll be shot out directly rather than sent in chunks. * Removed a bunch of the debugging I added to find out what was causing the stopping. * Enhanced the USR1 logging (try killall -USR1 mongrel_rails to toggle). It now reports numbers of threads waiting for each Rails request. USE THIS! * Minor clean-ups in API documentation. * Improved site documentation: * FAQ http://mongrel.rubyforge.org/faq.html * Apache http://mongrel.rubyforge.org/docs/apache.html * Debian http://mongrel.rubyforge.org/docs/debian-sarge.html PSTORE & MUTEX WARNING Every time I say this it tends to get drowned out by a flame war, so just to make sure: 1) Do not use pstore, and avoid anything that locks files like gdbm, etc. 2) Mutex causes leaks in our tests, if you have leaks, try Sync. People who have leaks using Mutex and switch to Sync say the problem is fixed for them too. 3) Make sure any 3rd party libraries you use are designed for use in multiple processes. This has caused many problems with people as well. OFFICIAL 0.3.13.4 I'm going to go through the bug tracker one last time, resolve any remaining issues, and if nobody reports any problems then I'm releasing 0.3.13.4 tonight. Do or die. Come chat with me in the lingr room if you have problems. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jaredbrown at gmail.com Sun Sep 3 16:28:38 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Sun, 3 Sep 2006 16:28:38 -0400 Subject: [Mongrel] Running multiple clusters Message-ID: I want to run two or more clusters for my rails application so that I can do a seamless update and not suffer any downtime. But I don't understand how to setup two clusters since there is only one mongrel config file. How would I go about doing this? -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060903/891204e7/attachment-0001.html From zedshaw at zedshaw.com Sun Sep 3 17:26:19 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 14:26:19 -0700 Subject: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- Docs and more Docs In-Reply-To: <1157312074.10409.40.camel@localhost.localdomain> References: <1157312074.10409.40.camel@localhost.localdomain> Message-ID: <1157318779.11883.2.camel@localhost.localdomain> On Sun, 2006-09-03 at 12:34 -0700, Zed Shaw wrote: > Hi Everyone, > > Just want to get out another ping on the Mongrel pre-release saga. I've > updated a bunch of the documentation to include documents people have > donated and to beef up the FAQ for most of the questions people have > asked over the past month. I messed up the gem, so grab it again please. Oh, and not for win32 yet. We're still fixing some stuff on that side of things. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jaredbrown at gmail.com Sun Sep 3 17:44:12 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Sun, 3 Sep 2006 17:44:12 -0400 Subject: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- Docs and more Docs In-Reply-To: <1157318779.11883.2.camel@localhost.localdomain> References: <1157312074.10409.40.camel@localhost.localdomain> <1157318779.11883.2.camel@localhost.localdomain> Message-ID: Any estimate on when the next version of mongrel_clusters going to be ready for primetime? On 9/3/06, Zed Shaw wrote: > > On Sun, 2006-09-03 at 12:34 -0700, Zed Shaw wrote: > > Hi Everyone, > > > > Just want to get out another ping on the Mongrel pre-release saga. I've > > updated a bunch of the documentation to include documents people have > > donated and to beef up the FAQ for most of the questions people have > > asked over the past month. > > I messed up the gem, so grab it again please. Oh, and not for win32 > yet. We're still fixing some stuff on that side of things. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060903/256b3a57/attachment.html From paul at paulbutcher.com Sun Sep 3 17:49:27 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Sun, 3 Sep 2006 22:49:27 +0100 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <1157308440.10409.27.camel@localhost.localdomain> Message-ID: <004b01c6cfa2$d416e680$7301a8c0@paullaptop> Zed wrote: > * Using the mysql.rb instead of installing the actual mysql compiled > gem. The mysql.rb is just for development, and it sucks horribly. Please forgive the stupid question, but how does one tell whether one is using the mysql compiled gem or not? I've installed it, apparently successfully, but I'd feel happier if I could be certain that Rails was using it... Thanks! -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From jan.svitok at gmail.com Sun Sep 3 18:11:22 2006 From: jan.svitok at gmail.com (Jan Svitok) Date: Mon, 4 Sep 2006 00:11:22 +0200 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <004b01c6cfa2$d416e680$7301a8c0@paullaptop> References: <1157308440.10409.27.camel@localhost.localdomain> <004b01c6cfa2$d416e680$7301a8c0@paullaptop> Message-ID: <8d9b3d920609031511i6ba6c632w258972358f26e732@mail.gmail.com> On 9/3/06, Paul Butcher wrote: > Please forgive the stupid question, but how does one tell whether one is > using the mysql compiled gem or not? I've installed it, apparently > successfully, but I'd feel happier if I could be certain that Rails was > using it... General procedure without really knowing too much about the drivers ;-) : either - try running coverage, to see which of them gets executed (probably too slow, too much work) - look at both versions to spot some differences in e.g. private method names and check it in your code. - try induce some exception in the mysql code and check the stack trace. - examine caller() inside a block called from some mysql stuff - the easiest one: look for some VERSION constant or similar thing. From gethemant at gmail.com Sun Sep 3 18:21:11 2006 From: gethemant at gmail.com (hemant) Date: Mon, 4 Sep 2006 03:51:11 +0530 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: <1157300677.6020.57.camel@localhost.localdomain> References: <1157300677.6020.57.camel@localhost.localdomain> Message-ID: Thanks Zed. On 9/3/06, Zed Shaw wrote: > > I'm spending today writing documentation. I'll be updating quite a few > documents, doing some edits, and adding some user contributed docs. If > anyone has documentation suggestions, FAQ questions they'd like > included, or things they think are old and stale, then let me know. > > Swing by the Lingr room: > > http://www.lingr.com/room/3yXhqKbfPy8 > > And drop me a line if you want to contribute something as well. > > Documents in the queue for editing today are: > > * FAQ -- Gonna clean out some old stuff and add a bunch of common > questions (suggestions welcome). > * FASQ -- I think I need to include some stupid questions people ask as > well. :-) > * Debian -- Finally got Chris McGrath's debian documentation up. > http://mongrel.rubyforge.org/docs/debian-sarge.html > * Apache -- Philip Hallstrom donate some initial Apache documentation > too. http://mongrel.rubyforge.org/docs/apache.html > * Adoptions -- I'm gonna add in success stories I haven't put in yet, > and if anyone has some more let me know. > * Mongrels -- Got a few new dogs and owners to put on. > > And that should get things going for the 0.3.13.4 release. If I can > find time then I'll update the plugins documentation to show how to > write handlers and such. > > Thanks! > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060904/2497f263/attachment.html From joshmh at gmail.com Sun Sep 3 18:45:16 2006 From: joshmh at gmail.com (Joshua Harvey) Date: Mon, 4 Sep 2006 01:45:16 +0300 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <8d9b3d920609031511i6ba6c632w258972358f26e732@mail.gmail.com> References: <1157308440.10409.27.camel@localhost.localdomain> <004b01c6cfa2$d416e680$7301a8c0@paullaptop> <8d9b3d920609031511i6ba6c632w258972358f26e732@mail.gmail.com> Message-ID: <3527dd260609031545i46719065j48de5c0873bfdc41@mail.gmail.com> Try: > irb irb> require 'mysql' If it works, you've got the compiled version, if it throws an exception, you don't. That's how Rails itself checks for it. -- Josh H. On 9/4/06, Jan Svitok wrote: > > On 9/3/06, Paul Butcher wrote: > > Please forgive the stupid question, but how does one tell whether one is > > using the mysql compiled gem or not? I've installed it, apparently > > successfully, but I'd feel happier if I could be certain that Rails was > > using it... > > General procedure without really knowing too much about the drivers ;-) : > either > - try running coverage, to see which of them gets executed (probably > too slow, too much work) > - look at both versions to spot some differences in e.g. private > method names and check it in your code. > - try induce some exception in the mysql code and check the stack trace. > - examine caller() inside a block called from some mysql stuff > - the easiest one: look for some VERSION constant or similar thing. > _______________________________________________ > 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/20060904/bfb7dbdf/attachment.html From jaredbrown at gmail.com Sun Sep 3 18:52:06 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Sun, 3 Sep 2006 18:52:06 -0400 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <3527dd260609031545i46719065j48de5c0873bfdc41@mail.gmail.com> References: <1157308440.10409.27.camel@localhost.localdomain> <004b01c6cfa2$d416e680$7301a8c0@paullaptop> <8d9b3d920609031511i6ba6c632w258972358f26e732@mail.gmail.com> <3527dd260609031545i46719065j48de5c0873bfdc41@mail.gmail.com> Message-ID: I am wondering the same thing. So what exactly are using to do in order to check? On 9/3/06, Joshua Harvey wrote: > > Try: > > > irb > irb> require 'mysql' > > If it works, you've got the compiled version, if it throws an exception, > you don't. That's how Rails itself checks for it. > > -- Josh H. > > > > On 9/4/06, Jan Svitok wrote: > > > > On 9/3/06, Paul Butcher wrote: > > > Please forgive the stupid question, but how does one tell whether one > > is > > > using the mysql compiled gem or not? I've installed it, apparently > > > successfully, but I'd feel happier if I could be certain that Rails > > was > > > using it... > > > > General procedure without really knowing too much about the drivers ;-) > > : either > > - try running coverage, to see which of them gets executed (probably > > too slow, too much work) > > - look at both versions to spot some differences in e.g. private > > method names and check it in your code. > > - try induce some exception in the mysql code and check the stack trace. > > - examine caller() inside a block called from some mysql stuff > > - the easiest one: look for some VERSION constant or similar thing. > > _______________________________________________ > > 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 > > -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060903/5db94255/attachment.html From jaredbrown at gmail.com Sun Sep 3 18:50:31 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Sun, 3 Sep 2006 18:50:31 -0400 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: References: <1157300677.6020.57.camel@localhost.localdomain> Message-ID: Maybe make a mention about using the mysql gem for Ruby, I noticed that right now you only have the edit to the environment.rb file up there. Also I have found this page to be infinately valuable, maybe it would be cool to through a link up for the various deployment configurations and put this one as the link for Apache 2.2.2 / Mod Proxy Balancer / Mongrel Cluster http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/ (not my site btw) On 9/3/06, hemant wrote: > > Thanks Zed. > > > On 9/3/06, Zed Shaw wrote: > > > > I'm spending today writing documentation. I'll be updating quite a few > > documents, doing some edits, and adding some user contributed docs. If > > anyone has documentation suggestions, FAQ questions they'd like > > included, or things they think are old and stale, then let me know. > > > > Swing by the Lingr room: > > > > http://www.lingr.com/room/3yXhqKbfPy8 > > > > And drop me a line if you want to contribute something as well. > > > > Documents in the queue for editing today are: > > > > * FAQ -- Gonna clean out some old stuff and add a bunch of common > > questions (suggestions welcome). > > * FASQ -- I think I need to include some stupid questions people ask as > > well. :-) > > * Debian -- Finally got Chris McGrath's debian documentation up. > > http://mongrel.rubyforge.org/docs/debian-sarge.html > > * Apache -- Philip Hallstrom donate some initial Apache documentation > > too. http://mongrel.rubyforge.org/docs/apache.html > > * Adoptions -- I'm gonna add in success stories I haven't put in yet, > > and if anyone has some more let me know. > > * Mongrels -- Got a few new dogs and owners to put on. > > > > And that should get things going for the 0.3.13.4 release. If I can > > find time then I'll update the plugins documentation to show how to > > write handlers and such. > > > > Thanks! > > > > -- > > Zed A. Shaw > > http://www.zedshaw.com/ > > http://mongrel.rubyforge.org/ > > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > -- > nothing much to talk > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060903/1149f26c/attachment-0001.html From wyhaines at gmail.com Sun Sep 3 19:10:09 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Sun, 3 Sep 2006 17:10:09 -0600 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <1157308440.10409.27.camel@localhost.localdomain> References: <1157300286.6020.50.camel@localhost.localdomain> <1157304031.10409.0.camel@localhost.localdomain> <1157308440.10409.27.camel@localhost.localdomain> Message-ID: On 9/3/06, Zed Shaw wrote: > But, explain this: > > http://pastie.caboo.se/10194 > > > vs. > > http://pastie.caboo.se/10317 > > First one leaks, second one doesn't (with graphs even). What's worse is > the inverse is true on win32. These scripts have no Mongrel code, no > Rails code, they're just short Ruby scripts. > > Now, it's not about users, it's about the two bug reductions that > simulate how Mongrel uses processes demonstrating a leak in both 1.8.5 > and 1.8.4. And it's insulting that you compare my careful examination > of the problem and numerous people's countless investigation into this > as nothing more than tribal Sun worship. If anything the Ruby morons > (not you) running around ignoring Ruby's problems are the religious > fanatics who need to get a grip and fix this crap before guys like me > get fed up and run happily to a platform that doesn't suck. No. People who thought that the sun revolved around the earth made a perfectly logical assumption, given the evidence that they observed. They were just missing some information that would have led them to a more accurate conclusion. When I read your original post about Mutex and Sync, and looked at the graphs, my first thought was, "Ugh. Maybe that's where my memory leak comes from!" I slept on it and when I woke in the morning, I dug into your test scripts, the code for Mutex and Sync, and the GC subsystem. I hacked the GC to give me detailed information about allocations, sweeps, free hash spots, etc... I modified your scripts to give me detailed object counts. I ran numerous variations of your tests. I couldn't find a leak. In fact, your test script itself (with Mutex) ate memory until it reached a stable point, then dropped a bit, then climbed back up to that stable point. I could make it behave worse by making the thread do something that actually creates a lot of garbage objects for the GC to deal with, but it still did not seem to be a leak. It did exhibit some curious behavior that I am not satisfied that I understand, though. When in a work loop that actually creates a lot of garbage objects, many, many more of them are accumulated when running under Mutex than when running under Sync. They seem to accumulate in greater numbers than they are cleared by the GC. However, doing nothing more than slowing the Mutex operation down to around the same speed as a Sync fixed that problem. Sync uses more up front resources, and is slower than Mutex. Both are implemented in pure ruby, and if Mutex leaks, there is no hope, because it is simpler than almost anything anybody writes in Ruby. Have you tried monitoring objectspace counts in a Mongrel process that appears to be leaking? Have you tried running it under valgrind? Have you tried putting diagnostic hooks into a specially compiled Ruby so that you can see when GC is called and when space is added to the heap while running a leaking Mongrel? I don't have any doubt at all that something funny is happening, but I have yet to see anything, including your test scripts and graphs, that actually indict Mutex. BTW, in my own case, I did end up finding a memory leak in Ruby. It was a stupid error in Hash causing some memory to never be freed. I would not be all surprised if there are other similar errors hiding in Ruby. Kirk Haines From zedshaw at zedshaw.com Sun Sep 3 23:05:29 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sun, 03 Sep 2006 20:05:29 -0700 Subject: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- Docs and more Docs In-Reply-To: References: <1157312074.10409.40.camel@localhost.localdomain> <1157318779.11883.2.camel@localhost.localdomain> Message-ID: <1157339129.6093.1.camel@localhost.localdomain> On Sun, 2006-09-03 at 17:44 -0400, Jared Brown wrote: > Any estimate on when the next version of mongrel_clusters going to be > ready for primetime? > Should be ready now. It's now part of the regular Mongrel builds so you can just get it the same way you get the mongrel pre-release. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From philippe.lachaise at gmail.com Mon Sep 4 03:57:44 2006 From: philippe.lachaise at gmail.com (philippe lachaise) Date: Mon, 4 Sep 2006 09:57:44 +0200 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: <1157300677.6020.57.camel@localhost.localdomain> References: <1157300677.6020.57.camel@localhost.localdomain> Message-ID: What about translations ? If/when some documents can be considered stable enough to be worth translating I would gladly take up some French translation. Not all (to say the least !) French software people understand English resonably well, so this effort would help make Mongrel popular in Frogland ;-) Philippe Lachaise. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060904/1664d7df/attachment.html From mail at flydown.org Mon Sep 4 04:32:27 2006 From: mail at flydown.org (Michele) Date: Mon, 4 Sep 2006 10:32:27 +0200 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: References: <1157300677.6020.57.camel@localhost.localdomain> Message-ID: Zed, I could help you translate the doc in Italian. Just drop me a line if you're interested. - Michele -- Michele Finotto http://finotto.org/ http://16bugs.com/ On Sep 4, 2006, at 9:57 , philippe lachaise wrote: > What about translations ? > > If/when some documents can be considered stable enough to be worth > translating I would gladly take up some French translation. > > Not all (to say the least !) French software people understand > English resonably well, so this effort would help make Mongrel > popular in Frogland ;-) > > Philippe Lachaise. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From krisleech at interkonect.com Mon Sep 4 05:44:30 2006 From: krisleech at interkonect.com (Kris Leech) Date: Mon, 04 Sep 2006 10:44:30 +0100 Subject: [Mongrel] balancer://mongrel_cluster Message-ID: <44FBF57E.7000306@interkonect.com> A couple of questions please: What is the benefit of having more than one Mongrel/Rails instance on the same machine, could one instance not serve as many requests as say three instances? Is Mongrel Cluster a Apache add-in (like mod_*) or a separately running load balancer which runs on a separate port, I could not work it out from the sample Apache config... |# Redirect all non-static requests to cluster RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] How does ||balancer://mongrel_cluster |work? Many thanks, K. From jeroen at supercool.nl Mon Sep 4 05:56:00 2006 From: jeroen at supercool.nl (Jeroen Houben) Date: Mon, 04 Sep 2006 11:56:00 +0200 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: <44FBF57E.7000306@interkonect.com> References: <44FBF57E.7000306@interkonect.com> Message-ID: <44FBF830.1000807@supercool.nl> Kris Leech wrote: > A couple of questions please: > > What is the benefit of having more than one Mongrel/Rails instance on > the same machine, could one instance not serve as many requests as say > three instances? > > Is Mongrel Cluster a Apache add-in (like mod_*) or a separately running > load balancer which runs on a separate port, I could not work it out > from the sample Apache config... > > |# Redirect all non-static requests to cluster > RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f > RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] > > How does ||balancer://mongrel_cluster |work? > My understanding is that one mongrel can only handle one request at a time. Therefore 3 mongrel can process 3 request simultaniously. The balancer is a module for apache >= 2.1 the balancer itself is not a seperate process, the pack of mongrels of course are seperate processes. HTH, Jeroen From krisleech at interkonect.com Mon Sep 4 06:14:51 2006 From: krisleech at interkonect.com (Kris Leech) Date: Mon, 04 Sep 2006 11:14:51 +0100 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: <44FBF830.1000807@supercool.nl> References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> Message-ID: <44FBFC9B.7050600@interkonect.com> Jeroen Houben wrote: >Kris Leech wrote: > > >>A couple of questions please: >> >>What is the benefit of having more than one Mongrel/Rails instance on >>the same machine, could one instance not serve as many requests as say >>three instances? >> >>Is Mongrel Cluster a Apache add-in (like mod_*) or a separately running >>load balancer which runs on a separate port, I could not work it out >>from the sample Apache config... >> >>|# Redirect all non-static requests to cluster >> RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f >> RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] >> >>How does ||balancer://mongrel_cluster |work? >> >> >> >My understanding is that one mongrel can only handle one request at a >time. Therefore 3 mongrel can process 3 request simultaniously. > > I see, and this is because Mongrel is not threaded, so its kind of like replicating threads by using whole instances. >The balancer is a module for apache >= 2.1 >the balancer itself is not a seperate process, the pack of mongrels of >course are seperate processes. > > Thanks, does it replace mod_proxy_balance? >HTH, > >Jeroen > > > >_______________________________________________ >Mongrel-users mailing list >Mongrel-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > From jeroen at supercool.nl Mon Sep 4 06:42:31 2006 From: jeroen at supercool.nl (Jeroen Houben) Date: Mon, 04 Sep 2006 12:42:31 +0200 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: <44FBFC9B.7050600@interkonect.com> References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> <44FBFC9B.7050600@interkonect.com> Message-ID: <44FC0317.5070707@supercool.nl> Kris Leech wrote: > Jeroen Houben wrote: > > >> Kris Leech wrote: >> >> >> >>> A couple of questions please: >>> >>> What is the benefit of having more than one Mongrel/Rails instance on >>> the same machine, could one instance not serve as many requests as say >>> three instances? >>> >>> Is Mongrel Cluster a Apache add-in (like mod_*) or a separately running >>> load balancer which runs on a separate port, I could not work it out >>> >> >from the sample Apache config... >> >>> |# Redirect all non-static requests to cluster >>> RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f >>> RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] >>> >>> How does ||balancer://mongrel_cluster |work? >>> >>> >>> >>> >> My understanding is that one mongrel can only handle one request at a >> time. Therefore 3 mongrel can process 3 request simultaniously. >> >> >> > I see, and this is because Mongrel is not threaded, so its kind of like > replicating threads by using whole instances. > Well I'm not entirely sure about that. I think mongrel can do threads but you really shouldn't use Rails with threads. http://david.planetargon.us/articles/2006/08/08/why-you-need-multiple-mongrel-instances-with-rails > >> The balancer is a module for apache >= 2.1 >> the balancer itself is not a seperate process, the pack of mongrels of >> course are seperate processes. >> >> >> > Thanks, does it replace mod_proxy_balance? > > No balancer://mongrel_cluster *is* mod_proxy_balancer, please look at http://mongrel.rubyforge.org/docs/apache.html for more details. Jeroen From g.vishnu at gmail.com Mon Sep 4 07:28:51 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Mon, 4 Sep 2006 16:58:51 +0530 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: <44FC0317.5070707@supercool.nl> References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> <44FBFC9B.7050600@interkonect.com> <44FC0317.5070707@supercool.nl> Message-ID: mongrel_cluster is installed with the mongrel gem and makes it easy to serve multiple mongrel instances. `mongrel_rails cluster::configure -h` for help. On 9/4/06, Jeroen Houben wrote: > Kris Leech wrote: > > Jeroen Houben wrote: > > > > > >> Kris Leech wrote: > >> > >> > >> > >>> A couple of questions please: > >>> > >>> What is the benefit of having more than one Mongrel/Rails instance on > >>> the same machine, could one instance not serve as many requests as say > >>> three instances? > >>> > >>> Is Mongrel Cluster a Apache add-in (like mod_*) or a separately running > >>> load balancer which runs on a separate port, I could not work it out > >>> > >> >from the sample Apache config... > >> > >>> |# Redirect all non-static requests to cluster > >>> RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f > >>> RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] > >>> > >>> How does ||balancer://mongrel_cluster |work? > >>> > >>> > >>> > >>> > >> My understanding is that one mongrel can only handle one request at a > >> time. Therefore 3 mongrel can process 3 request simultaniously. > >> > >> > >> > > I see, and this is because Mongrel is not threaded, so its kind of like > > replicating threads by using whole instances. > > > Well I'm not entirely sure about that. I think mongrel can do threads > but you really shouldn't use Rails with threads. > http://david.planetargon.us/articles/2006/08/08/why-you-need-multiple-mongrel-instances-with-rails > > > >> The balancer is a module for apache >= 2.1 > >> the balancer itself is not a seperate process, the pack of mongrels of > >> course are seperate processes. > >> > >> > >> > > Thanks, does it replace mod_proxy_balance? > > > > > No balancer://mongrel_cluster *is* mod_proxy_balancer, please look at > http://mongrel.rubyforge.org/docs/apache.html for more details. > > Jeroen > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From g.vishnu at gmail.com Mon Sep 4 09:30:25 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Mon, 4 Sep 2006 19:00:25 +0530 Subject: [Mongrel] Mongrel Tuneup Guide: Questions Message-ID: Hi! I've been following the new mongrel tuneup guide (a huge thanks for that btw) and here are my results. I've basically only gotten to the point where I'm tuning up 1 mongrel because I suspect I have a performance problem with my rails app. http://mongrel.rubyforge.org/docs/how_many_mongrels.html The first number is the 10s nconns and the second is the max req/s as per the guide: Lighttpd serving static files: 6000 1800 1 Mongrel serving static files: 2800 200 1 Mongrel serving a bare /login page (without db query, no layout, just an action): 750 50 1 Mongrel serving my full /index page (many db queries, render with layout) 80 7 Right, so I guess my "rails measurement is horribly slow". The thing is, I've worked on the /index page a lot. I've implemented memcached, so db queries are basically minimal, and so the bottlneck basically is like this: The index page doesn't have any components, just 1 partial (called 2 times). logs (in debug mode) look like this (for /index): Completed in 0.21839 (4 reqs/sec) | Rendering: 0.16793 (76%) | DB: 0.02759 (12%) What do I do to optimize this situation? Think I'm missing something here... P.S. I'm running FreeBSD on a Celeron 2.0Ghz/2GB ram. And my processer is at 100% peak mostly when I'm hitting the load. Vish From hutch at recursive.ca Mon Sep 4 09:40:59 2006 From: hutch at recursive.ca (Bob Hutchison) Date: Mon, 4 Sep 2006 09:40:59 -0400 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: References: <1157300286.6020.50.camel@localhost.localdomain> <1157304031.10409.0.camel@localhost.localdomain> <1157308440.10409.27.camel@localhost.localdomain> Message-ID: <83B8A776-7A05-4931-826A-E20AAF98A667@recursive.ca> On Sep 3, 2006, at 7:10 PM, Kirk Haines wrote: > I don't have any doubt at all that something funny is happening, but I > have yet to see anything, including your test scripts and graphs, that > actually indict Mutex. I posted something on the ruby talk list that directly pointed at Mutex. Yes, Mutex sooner-or-later stabilises, but that really can be later rather than sooner. Try this, run your test but this time remove all references to the Mutex before garbage collecting. Watch what (doesn't) happen. Sync doesn't have this problem. Cheers, Bob ---- Bob Hutchison -- blogs at Recursive Design Inc. -- Raconteur -- xampl for Ruby -- From jacob at jacobatzen.dk Mon Sep 4 11:02:19 2006 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Mon, 4 Sep 2006 17:02:19 +0200 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <1157300286.6020.50.camel@localhost.localdomain> References: <1157300286.6020.50.camel@localhost.localdomain> Message-ID: <20060904150219.GA3260@nezbo.dhcp.aub.dk> On Sun, Sep 03, 2006 at 09:18:06AM -0700, Zed Shaw wrote: > 2) DON'T STORE COMPLEX OBJECTS IN THE SESSION! > > This especially goes for you Java people who think the session store is > a temporary database. The session really only works for simple types > like integers, strings, etc. You *must* follow the mantra of "Share > Nothing" and either store everything in the database or use form fields > and GET parameters to make it stateless. As I've said repeatedly, "If > rails-core don't do it, you don't do it." Rails-core does not do this. > You don't do it. This piece of advice I find a little troubling. Often you have to store a lot of data temporarily in your application, f.ex. with multipage form submissions. Having to store only simple types will make this much more complicated compared to simply storing a single object in the session which is repeatedly updated until stored in the database. Is the data in the session not simply marshalled and then read back on the next request? If so, what is the difference between simple and complex types, they should marshal and unmarshal equally well, yes? Am I missing something here? -- Thanks, - Jacob Atzen From hutch at recursive.ca Mon Sep 4 11:33:31 2006 From: hutch at recursive.ca (Bob Hutchison) Date: Mon, 4 Sep 2006 11:33:31 -0400 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <20060904150219.GA3260@nezbo.dhcp.aub.dk> References: <1157300286.6020.50.camel@localhost.localdomain> <20060904150219.GA3260@nezbo.dhcp.aub.dk> Message-ID: <81B3317D-1FB1-42D9-9ACF-393DD518AE08@recursive.ca> On Sep 4, 2006, at 11:02 AM, Jacob Atzen wrote: > On Sun, Sep 03, 2006 at 09:18:06AM -0700, Zed Shaw wrote: >> 2) DON'T STORE COMPLEX OBJECTS IN THE SESSION! >> >> This especially goes for you Java people who think the session >> store is >> a temporary database. The session really only works for simple types >> like integers, strings, etc. You *must* follow the mantra of "Share >> Nothing" and either store everything in the database or use form >> fields >> and GET parameters to make it stateless. As I've said repeatedly, >> "If >> rails-core don't do it, you don't do it." Rails-core does not do >> this. >> You don't do it. > > This piece of advice I find a little troubling. Often you have to > store > a lot of data temporarily in your application, f.ex. with multipage > form > submissions. Having to store only simple types will make this much > more > complicated compared to simply storing a single object in the session > which is repeatedly updated until stored in the database. > > Is the data in the session not simply marshalled and then read back on > the next request? If so, what is the difference between simple and > complex types, they should marshal and unmarshal equally well, yes? This is true of all webapp servers I've ever used that serialises/ restores sessions. The source of trouble I've encountered is where there is some sort of object identity that the application is assuming. This can be very subtle. "Share nothing" is one solution, the other is to rely on some mechanism (say the DB, or in my case, xampl) to manage this for you. (If you are thinking of storing what amounts to structured data, then you are probably okay, except that this inevitably evolves into something else and you'll end up trying to debug a nasty situation and you'll be looking at the change that did it and that'll be nowhere near where the problem actually is.) I'm sure there are other problems, and they'll be subtle too. Cheers, Bob > > Am I missing something here? > > -- > Thanks, > - Jacob Atzen > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users ---- Bob Hutchison -- blogs at Recursive Design Inc. -- Raconteur -- xampl for Ruby -- From hutch at recursive.ca Mon Sep 4 11:35:03 2006 From: hutch at recursive.ca (Bob Hutchison) Date: Mon, 4 Sep 2006 11:35:03 -0400 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <20060904150219.GA3260@nezbo.dhcp.aub.dk> References: <1157300286.6020.50.camel@localhost.localdomain> <20060904150219.GA3260@nezbo.dhcp.aub.dk> Message-ID: <5524926D-42DF-4498-BE74-6A8BE36C0196@recursive.ca> On Sep 4, 2006, at 11:02 AM, Jacob Atzen wrote: > On Sun, Sep 03, 2006 at 09:18:06AM -0700, Zed Shaw wrote: >> 2) DON'T STORE COMPLEX OBJECTS IN THE SESSION! >> >> This especially goes for you Java people who think the session >> store is >> a temporary database. The session really only works for simple types >> like integers, strings, etc. You *must* follow the mantra of "Share >> Nothing" and either store everything in the database or use form >> fields >> and GET parameters to make it stateless. As I've said repeatedly, >> "If >> rails-core don't do it, you don't do it." Rails-core does not do >> this. >> You don't do it. > > This piece of advice I find a little troubling. Often you have to > store > a lot of data temporarily in your application, f.ex. with multipage > form > submissions. Having to store only simple types will make this much > more > complicated compared to simply storing a single object in the session > which is repeatedly updated until stored in the database. > > Is the data in the session not simply marshalled and then read back on > the next request? If so, what is the difference between simple and > complex types, they should marshal and unmarshal equally well, yes? This is true of all webapp servers I've ever used that serialises/ restores sessions. The source of trouble I've encountered is where there is some sort of object identity that the application is assuming. This can be very subtle. "Share nothing" is one solution, the other is to rely on some mechanism (say the DB, or in my case, xampl) to manage this for you. (If you are thinking of storing what amounts to structured data, then you are probably okay, except that this inevitably evolves into something else and you'll end up trying to debug a nasty situation and you'll be looking at the change that did it and that'll be nowhere near where the problem actually is.) I'm sure there are other problems, and they'll be subtle too. Cheers, Bob > > Am I missing something here? > > -- > Thanks, > - Jacob Atzen > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users ---- Bob Hutchison -- blogs at Recursive Design Inc. -- Raconteur -- xampl for Ruby -- From jeroen at supercool.nl Mon Sep 4 13:07:50 2006 From: jeroen at supercool.nl (Jeroen Houben) Date: Mon, 04 Sep 2006 19:07:50 +0200 Subject: [Mongrel] first request always fails In-Reply-To: <1157293446.6020.8.camel@localhost.localdomain> References: <44FAE2D6.2010602@supercool.nl> <1157293446.6020.8.camel@localhost.localdomain> Message-ID: <44FC5D66.7000800@supercool.nl> Zed Shaw wrote: > On Sun, 2006-09-03 at 16:12 +0200, Jeroen Houben wrote: >> Hi, >> >> Whenever I restart mongrel on my production server, the first request in >> my browser always fails, I get this error: >> >> Processing Base#index (for 83.xx.xx.xx at 2006-09-03 16:08:47) [GET] >> Session ID: f1918346d193e19a70c3230286e5ce1a >> Parameters: {} >> >> >> TypeError (superclass mismatch for class Stats): >> /app/models/stats.rb:1 > > Ah, there's a Stats class already in Mongrel but it's not in the mongrel > module. I'll move that over and see if it breaks anyone. > > Zed, could you maybe tell me if this change is going to be in the next release? I'll be happy to report back my experience after installing it of course. Jeroen From guido at sohne.net Mon Sep 4 13:41:36 2006 From: guido at sohne.net (Guido Sohne) Date: Mon, 4 Sep 2006 17:41:36 +0000 Subject: [Mongrel] Application performance In-Reply-To: <1157151310.6146.36.camel@localhost.localdomain> References: <1157151310.6146.36.camel@localhost.localdomain> Message-ID: You can also send model objects over to the page you are rendering as JSON and work directly from them, and only post when you need to. It is going to mean a lot of JavaScript work and something like the Unobtrusive Javascripts plugin can help you make it a less painful experience. Expect to spend more time debugging, though ... -- G. From david at vrensk.com Mon Sep 4 13:47:04 2006 From: david at vrensk.com (David Vrensk) Date: Mon, 4 Sep 2006 19:47:04 +0200 Subject: [Mongrel] custom error handling In-Reply-To: <683a886f0609020726u77cb40a3jc6d2eb9b87b8c78e@mail.gmail.com> References: <683a886f0609020726u77cb40a3jc6d2eb9b87b8c78e@mail.gmail.com> Message-ID: <81b453920609041047h7fb30174l9988554a24cb8f37@mail.gmail.com> On 9/2/06, Kevin Williams wrote: > > Please forgive me if this is a stupid question. It's not stupid, but it's not mongrel-specific either, so I suggest we take further discussion off-list. How can I programatically handle 404s and 500s when using Mongrel? Check out the exception notifcation plugin: script/plugin install exception_notification If you prefer to do it yourself, look in ActionController::Rescue # Overwrite to implement public exception handling (for requests answering false to local_request?). def rescue_action_in_public(exception) #:doc: case exception when RoutingError, UnknownAction then render_text(IO.read(File.join(RAILS_ROOT, 'public', '404.html')), "404 Not Found") else render_text "

Application error (Rails)

" end end which defines the stuff that is run by default. And as the comment says: Overwrite! HTH, /David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060904/7e9ffb52/attachment.html From wyhaines at gmail.com Mon Sep 4 13:50:21 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 4 Sep 2006 11:50:21 -0600 Subject: [Mongrel] The real reason why Sync and Mutex behave differently Message-ID: As I've mentioned before, Sync and Mutex are very similar, and Mutex is very simple. Their locking algorithm (for exclusive locking) is essentially identical. And in some detailed examinations of Mutex's behavior, there's nothing superficially wrong with it. It's pure ruby, so there are no funny memory allocations at the C level, and it essentially operates by using an array as a queue for waiting threads. Very little is involved. Sync does a bunch of other things, since it supports shared locking in addition to exclusive, so it is much more complicated. However, the main difference between them, when one is using exclusive locking, is in the way they perform unlocking. Mutex: Thread.critical = true @locked = false begin t = @waiting.shift t.wakeup if t rescue ThreadError retry end Thread.critical = false begin t.run if t rescue ThreadError end self With Mutex, the next thread to unlock is shifted off the beginning of the array. With Sync, there is one key difference: wait = sync_waiting self.sync_waiting = [] Thread.critical = false for w in wait w.run end With Sync, a copy is made of the array or waiting threads, the waiting thread queue is set to a fresh, empty array, and all of the threads pointed to in the copy are woken up. One will get the lock, and the rest insert themselves back into the waiting queue. That copy of the sync_waiting array, "wait", which is now the only thing pointing at the original array, then gets thrown away, letting it get garbage collected. That's the key to the difference, right there. With Mutex, the shift operation reduces the size of the array, but shift never reallocs. With Sync, that array gets thrown away, and when gc runs, it is cleaned up. This whole thing with Mutex hinges on the memory management behavior in array.c. This is why throwing away the mutex and creating a new one between iterations in that test script produces a result similar to what Sync produces, too, as the net effect is that the array that the mutex uses to track threads gets thrown away. I made a copy of Mutex and changed it to use a linked list instead of an array to queue waiting threads, thereby eliminating array.c from the mix while keeping the rest of Mutex.rb intact, and I now get completely perfect, deterministic behavior on both Linux and Win XP. array.c's behavior is what needs to be examined in greater detail, here. Kirk Haines From zedshaw at zedshaw.com Mon Sep 4 14:10:44 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 04 Sep 2006 11:10:44 -0700 Subject: [Mongrel] first request always fails In-Reply-To: <44FC5D66.7000800@supercool.nl> References: <44FAE2D6.2010602@supercool.nl> <1157293446.6020.8.camel@localhost.localdomain> <44FC5D66.7000800@supercool.nl> Message-ID: <1157393444.6520.7.camel@localhost.localdomain> On Mon, 2006-09-04 at 19:07 +0200, Jeroen Houben wrote: > Zed Shaw wrote: > > > > Ah, there's a Stats class already in Mongrel but it's not in the mongrel > > module. I'll move that over and see if it breaks anyone. > > > > > > Zed, could you maybe tell me if this change is going to be in the next > release? > > I'll be happy to report back my experience after installing it of course. Yep, it's on my list. If you're in a hurry though you should change it to Statistics now. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From wyhaines at gmail.com Mon Sep 4 14:24:02 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 4 Sep 2006 12:24:02 -0600 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: <44FBFC9B.7050600@interkonect.com> References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> <44FBFC9B.7050600@interkonect.com> Message-ID: On 9/4/06, Kris Leech wrote: > Jeroen Houben wrote: > >My understanding is that one mongrel can only handle one request at a > >time. Therefore 3 mongrel can process 3 request simultaniously. > > > > > I see, and this is because Mongrel is not threaded, so its kind of like > replicating threads by using whole instances. Mongrel is threaded. It will create a new thread for each connection. However, Rails does bad, unfriendly things when one tries to run multiple threads of it at the same time. So the Mongrel handler for Rails synchronizes Rails calls so that only one runs at a time. Thus, to handle simultaneous Rails requests with Mongrel one needs more than one Mongrel process. Kirk Haines Kirk Haines From gethemant at gmail.com Mon Sep 4 14:24:53 2006 From: gethemant at gmail.com (hemant) Date: Mon, 4 Sep 2006 23:54:53 +0530 Subject: [Mongrel] mongrel thread safety and global variables In-Reply-To: <1157199374.9315.0.camel@localhost.localdomain> References: <1157150250.6146.20.camel@localhost.localdomain> <71166b3b0609011650h748675car263a098dbff3000d@mail.gmail.com> <71166b3b0609012334x4e28dbbfm8cdafaa31faa843@mail.gmail.com> <1157199374.9315.0.camel@localhost.localdomain> Message-ID: Well, I think i have figured out the problem with my code (*but i am not entirely sure..so please correct me if i am wrong) If you look at above code, then you will see: begin timeout(6) do # read from socket end rescue Timeout::Error # error handling end My assertion says, sometimes for certain protocol codes, the time to read from the socket is more than 6 seconds and hence that "gets request" is timed out there. Now..in the next call, when i put some new request to the socket...i get response for the previous request, because socket still contains data that was written to it after the timeout. Ugly,right? Solution I have thought is: 1. Send a unique GUID as a extended modifier with each request and expect that proxy will echo it to us. 2. Somehow clear the socket, before read...not entirely sure abt this.Somebody on ruby-lang also suggested that, use Eventmachine. On 9/2/06, Zed Shaw wrote: > > On Sat, 2006-09-02 at 17:00 +0530, hemant wrote: > > Yes...its a multithreaded and supposed to server request flawlessly. > > > > BTW, as a quick check...i wrote a ruby program to fetch data for some > > 10000 iterations and and append it to a CSV file...and didn't get a > > single data mangling error. > > > > Next step, I will try 100 simultaneous threads, fetching the data and > > see if there is a mis-match. > > And randomize it. Ruby's threads work fairly predictably so without a > random short think time to mix things up you won't get good results. > > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060904/3c61ee8b/attachment.html From gethemant at gmail.com Mon Sep 4 14:31:38 2006 From: gethemant at gmail.com (hemant) Date: Tue, 5 Sep 2006 00:01:38 +0530 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> <44FBFC9B.7050600@interkonect.com> Message-ID: Somebody asked similar question earlier i guess...why run multiple instances of mongrel..when it is threaded? The simple answer is...ruby threads are not native threads.And hence..all the ruby threads are running your current interpretor. Also, if you have multi-core CPUs..you won't be able to take advantage of that with single mongrel process..even though it is threaded and hence in production mode....you should run 8 to 10 mongrel servers( as per official documentation,but depends upon your hardware and hit rate) Again..i could be wrong..but thats my humble opinion. On 9/4/06, Kirk Haines wrote: > > On 9/4/06, Kris Leech wrote: > > Jeroen Houben wrote: > > > >My understanding is that one mongrel can only handle one request at a > > >time. Therefore 3 mongrel can process 3 request simultaniously. > > > > > > > > I see, and this is because Mongrel is not threaded, so its kind of like > > replicating threads by using whole instances. > > Mongrel is threaded. It will create a new thread for each connection. > However, Rails does bad, unfriendly things when one tries to run > multiple threads of it at the same time. So the Mongrel handler for > Rails synchronizes Rails calls so that only one runs at a time. Thus, > to handle simultaneous Rails requests with Mongrel one needs more than > one Mongrel process. > > > Kirk Haines > > > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060905/2c683866/attachment.html From zedshaw at zedshaw.com Mon Sep 4 14:32:44 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 04 Sep 2006 11:32:44 -0700 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <20060904150219.GA3260@nezbo.dhcp.aub.dk> References: <1157300286.6020.50.camel@localhost.localdomain> <20060904150219.GA3260@nezbo.dhcp.aub.dk> Message-ID: <1157394764.6520.27.camel@localhost.localdomain> On Mon, 2006-09-04 at 17:02 +0200, Jacob Atzen wrote: > On Sun, Sep 03, 2006 at 09:18:06AM -0700, Zed Shaw wrote: > > 2) DON'T STORE COMPLEX OBJECTS IN THE SESSION! > > > > This especially goes for you Java people who think the session store is > > a temporary database. The session really only works for simple types > > like integers, strings, etc. You *must* follow the mantra of "Share > > Nothing" and either store everything in the database or use form fields > > and GET parameters to make it stateless. As I've said repeatedly, "If > > rails-core don't do it, you don't do it." Rails-core does not do this. > > You don't do it. > > This piece of advice I find a little troubling. Often you have to store > a lot of data temporarily in your application, f.ex. with multipage form > submissions. Having to store only simple types will make this much more > complicated compared to simply storing a single object in the session > which is repeatedly updated until stored in the database. > > Is the data in the session not simply marshalled and then read back on > the next request? If so, what is the difference between simple and > complex types, they should marshal and unmarshal equally well, yes? > > Am I missing something here? > I generally do these things to work with large objects that are built in stages: 1) Include a "state" variable that determines what stage of its preparation it is currently at. This gets saved and updated as you operate making it possible to restore it to where it needs to continue. Very handy in situations where people need to save their job and come back. 2) Store only the object id in the user's session, or better yet associate the user with the object(s) being built and call that association their "queue". This lets them create and manage jobs as needed. 3) Make the larger object composed of smaller object representing the parts that make up your forms/stages. This lets you put the validations in the smaller objects and save them as the user goes, but then use a large complete object later. 4) If you have to use one giganto object then find a way to either not do validations or do them in a delayed fashion (this is a royal pain). 5) Finally, use Ajax in key places to make building and modifying the smaller objects more seamless. Staged forms are kind of an addiction in business process redesign, and many times when you're forced to break the process down into smaller data objects you begin to see a pattern that lets you redesign the process to be simpler. Many times what you think are discrete stages are actually very similar. But, if you've *got* to use a staged form process then really use the state field to implement a state machine. This gives you more error correction capabilities and makes it easier to translate people's in process work when the state machine changes. You just run a migration that moves everyone to the new required state, or zaps their in process work (if that's possible). Another thing you'll find is that this is faster than session storage because AR (and many ORM) store only the deltas. Since smaller data chunks are getting saved between form views it tends to go quicker than saving the whole massive blob to the session after marshaling. Hope that helps. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Mon Sep 4 14:49:50 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 04 Sep 2006 11:49:50 -0700 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: References: <1157300677.6020.57.camel@localhost.localdomain> Message-ID: <1157395790.6520.31.camel@localhost.localdomain> Michele, and Philippe, On Mon, 2006-09-04 at 10:32 +0200, Michele wrote: > Zed, > > I could help you translate the doc in Italian. > Just drop me a line if you're interested. That'd be really cool actually. The documentation is very easy to take and modify/create. I've got a page on how to do it and how to contribute documentation: http://mongrel.rubyforge.org/docs/contrib.html It describes how to check the documentation out, how to get webgen and use it to build the site locally, and what kind of documentation is expected. I'm thinking if you want to do a translation to French and Italian then we can pick a few key documents, create two subdirectories /fr and /it and then copy the docs over once translated. What do you think? Maybe we can recruit some others for the translation. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Mon Sep 4 14:50:18 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 04 Sep 2006 11:50:18 -0700 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: References: <1157300677.6020.57.camel@localhost.localdomain> Message-ID: <1157395818.6520.33.camel@localhost.localdomain> On Mon, 2006-09-04 at 09:57 +0200, philippe lachaise wrote: > What about translations ? > > If/when some documents can be considered stable enough to be worth > translating I would gladly take up some French translation. > > Not all (to say the least !) French software people understand English > resonably well, so this effort would help make Mongrel popular in > Frogland ;-) That'd be very cool. See my reply to Michele's message about Italian for what I think could be a plan. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From mail at flydown.org Mon Sep 4 15:01:53 2006 From: mail at flydown.org (Michele) Date: Mon, 4 Sep 2006 21:01:53 +0200 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: <1157395790.6520.31.camel@localhost.localdomain> References: <1157300677.6020.57.camel@localhost.localdomain> <1157395790.6520.31.camel@localhost.localdomain> Message-ID: <1E6BAE3A-4DCD-41DA-BE01-97B07CC4E79A@flydown.org> Zed, Sounds good to me. I'll start working on this immediately and get back to you as soon as I have something ready. - Michele -- Michele Finotto http://finotto.org/ http://16bugs.com/ On Sep 4, 2006, at 20:49 , Zed Shaw wrote: > Michele, and Philippe, > > On Mon, 2006-09-04 at 10:32 +0200, Michele wrote: >> Zed, >> >> I could help you translate the doc in Italian. >> Just drop me a line if you're interested. > > That'd be really cool actually. The documentation is very easy to > take > and modify/create. I've got a page on how to do it and how to > contribute documentation: > > http://mongrel.rubyforge.org/docs/contrib.html > > It describes how to check the documentation out, how to get webgen and > use it to build the site locally, and what kind of documentation is > expected. > > I'm thinking if you want to do a translation to French and Italian > then > we can pick a few key documents, create two subdirectories /fr and /it > and then copy the docs over once translated. > > What do you think? Maybe we can recruit some others for the > translation. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From philippe.lachaise at gmail.com Mon Sep 4 15:15:49 2006 From: philippe.lachaise at gmail.com (philippe lachaise) Date: Mon, 4 Sep 2006 21:15:49 +0200 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: <1E6BAE3A-4DCD-41DA-BE01-97B07CC4E79A@flydown.org> References: <1157300677.6020.57.camel@localhost.localdomain> <1157395790.6520.31.camel@localhost.localdomain> <1E6BAE3A-4DCD-41DA-BE01-97B07CC4E79A@flydown.org> Message-ID: Sounds good to me too. I'll take a closer look at instructions tomorrow and I'll try and get started ASAP. Philippe. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060904/373ef14a/attachment-0001.html From zedshaw at zedshaw.com Mon Sep 4 15:22:09 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 04 Sep 2006 12:22:09 -0700 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: <1E6BAE3A-4DCD-41DA-BE01-97B07CC4E79A@flydown.org> References: <1157300677.6020.57.camel@localhost.localdomain> <1157395790.6520.31.camel@localhost.localdomain> <1E6BAE3A-4DCD-41DA-BE01-97B07CC4E79A@flydown.org> Message-ID: <1157397729.6520.35.camel@localhost.localdomain> On Mon, 2006-09-04 at 21:01 +0200, Michele wrote: > Zed, > > Sounds good to me. I'll start working on this immediately and get > back to you as soon as I have something ready. Nice, feel free to stop by the lingr room to chat about it. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Mon Sep 4 15:25:12 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 04 Sep 2006 12:25:12 -0700 Subject: [Mongrel] [ANN] Documentation Day! In-Reply-To: References: <1157300677.6020.57.camel@localhost.localdomain> <1157395790.6520.31.camel@localhost.localdomain> <1E6BAE3A-4DCD-41DA-BE01-97B07CC4E79A@flydown.org> Message-ID: <1157397912.6520.37.camel@localhost.localdomain> On Mon, 2006-09-04 at 21:15 +0200, philippe lachaise wrote: > Sounds good to me too. > > I'll take a closer look at instructions tomorrow and I'll try and get > started ASAP. Cool, and swing by the lingr room (see my signature) to discuss anything. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From gethemant at gmail.com Mon Sep 4 19:19:30 2006 From: gethemant at gmail.com (hemant) Date: Tue, 5 Sep 2006 04:49:30 +0530 Subject: [Mongrel] mongrel proxies waiting endlessly Message-ID: Sometime my mongrel server threads..would simply stop responding to the requests...and in the logs i get following error: Tue Sep 05 03:56:40 IST 2006: ERROR: Transport endpoint is not connected - getpeername(2) Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not connected - getpeername(2) Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not connected - getpeername(2) Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not connected - getpeername(2) Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not connected - getpeername(2) Any clues? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060905/051fde52/attachment.html From zedshaw at zedshaw.com Mon Sep 4 19:37:39 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 04 Sep 2006 16:37:39 -0700 Subject: [Mongrel] [ANN] Mongrel Upload Progress 0.2 -- With Instructions and Examples Message-ID: <1157413059.6217.10.camel@localhost.localdomain> Hi Folks, I'm sure tons of people are gonna ruin a whole drawer of their best panties over this one. Rick Olson worked on the mongrel_upload_progress gem, documentation and examples and has almost everything you need to do progress tracked file uploads using just Mongrel to handle the upload. This means that Rails (or any other framework) isn't blocked while the upload happens, and that the user gets nice status. Here's Rick's blog post: http://weblog.techno-weenie.net/2006/9/4/mongrel-upload-progress-documentation You can watch a snazzy video of Rick playing with it at: http://s3.amazonaws.com/techno-weenie-screencasts/mongrel_drb.mov Then you can read the instructions and get sample code from: http://mongrel.rubyforge.org/docs/upload_progress.html Which includes installation instructions, sample rhtml forms, javascript, and Rails actions to get you started. It's not limited to Rails though, that's just the example Rick did, since, well, Rick does Rails. This is still early, so patches and suggestions are welcome. And everyone should thank Rick and _why_t_l_s for working on this with me at RailsConf, and especially Rick for doing the heavy lifting of integrating it with Rails and documenting it. WRITING PLUGINS The m_u_p gem is also a good example of writing a fairly complex plugin for Mongrel that is easy to install. Take a look if you want to do similar fancy hackery. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Mon Sep 4 19:39:31 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 04 Sep 2006 16:39:31 -0700 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: References: Message-ID: <1157413171.6217.12.camel@localhost.localdomain> On Tue, 2006-09-05 at 04:49 +0530, hemant wrote: > Sometime my mongrel server threads..would simply stop responding to > the requests...and in the logs i get following error: > > Tue Sep 05 03:56:40 IST 2006: ERROR: Transport endpoint is not > connected - getpeername(2) > Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not > connected - getpeername(2) > Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not > connected - getpeername(2) > Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not > connected - getpeername(2) > Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not > connected - getpeername(2) Make sure you have the latest 0.3.13.4 pre-release, run your code under it, and after mongrel starts, turn on USR1 debugging: killall -USR1 mongrel_rails Then, look for any logging messages in mongrel.log that say there's tons of threads waiting for one of your rails actions. Go fix that rails action and you'll be set. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From gethemant at gmail.com Mon Sep 4 20:00:00 2006 From: gethemant at gmail.com (hemant) Date: Tue, 5 Sep 2006 05:30:00 +0530 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: <1157413171.6217.12.camel@localhost.localdomain> References: <1157413171.6217.12.camel@localhost.localdomain> Message-ID: On 9/5/06, Zed Shaw wrote: > > On Tue, 2006-09-05 at 04:49 +0530, hemant wrote: > > Sometime my mongrel server threads..would simply stop responding to > > the requests...and in the logs i get following error: > > > > Tue Sep 05 03:56:40 IST 2006: ERROR: Transport endpoint is not > > connected - getpeername(2) > > Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not > > connected - getpeername(2) > > Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not > > connected - getpeername(2) > > Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not > > connected - getpeername(2) > > Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not > > connected - getpeername(2) > > Make sure you have the latest 0.3.13.4 pre-release, run your code under > it, and after mongrel starts, turn on USR1 debugging: > > killall -USR1 mongrel_rails > > Then, look for any logging messages in mongrel.log that say there's tons > of threads waiting for one of your rails actions. Go fix that rails > action and you'll be set. > I was using killall -USR1, but in your recent post..i have seen that you have updated the pre-release server...and hence i update the mongrel gem and..i am debugging it again.. Tue Sep 05 05:03:32 IST 2006: 0 threads sync_waiting for /images/tab_but_normal1.png, 4 still active in mongrel. So, what does the above line mean? 4 still active in mongrel? does it mean that 4 threads are waiting for this file? Does it mean..that for every file that is not found...in the rails application directory, mongrel threads wait? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060905/5be20117/attachment.html From zedshaw at zedshaw.com Mon Sep 4 20:08:37 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 04 Sep 2006 17:08:37 -0700 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: References: <1157413171.6217.12.camel@localhost.localdomain> Message-ID: <1157414917.6353.2.camel@localhost.localdomain> On Tue, 2006-09-05 at 05:30 +0530, hemant wrote: > On 9/5/06, Zed Shaw wrote: > > I was using killall -USR1, but in your recent post..i have seen that > you have updated the pre-release server...and hence i update the > mongrel gem and..i am debugging it again.. > > Tue Sep 05 05:03:32 IST 2006: 0 threads sync_waiting > for /images/tab_but_normal1.png, 4 still active in mongrel. > > So, what does the above line mean? 4 still active in mongrel? does it > mean that 4 threads are waiting for this file? > > Does it mean..that for every file that is not found...in the rails > application directory, mongrel threads wait? > It means that a request came in, it hit rails, there were 0 waiting for rails, and there's still 4 "in mongrel". These four are probably busy sending a response. What you don't want to see is: Tue Sep 05 05:03:32 IST 2006: 980 threads sync_waiting for /images/tab_but_normal1.png, 975 still active in mongrel. Additionally, why in the world are you having Mongrel serve the files. Please, please, please configure your apache correctly so that apache serves the files and mongrel just does Rails. You'd be way better off just doing that. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From gethemant at gmail.com Mon Sep 4 20:15:10 2006 From: gethemant at gmail.com (hemant) Date: Tue, 5 Sep 2006 05:45:10 +0530 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: <1157414917.6353.2.camel@localhost.localdomain> References: <1157413171.6217.12.camel@localhost.localdomain> <1157414917.6353.2.camel@localhost.localdomain> Message-ID: Yes yes..the message i have reported is currently from my development instance. For main instance...Apache is configured to server static pages. Do these threads add up? Currently it is: Tue Sep 05 05:31:11 IST 2006: 0 threads sync_waiting for /charts/%5ENSEI, 1 still active in mongrel. Tue Sep 05 05:31:26 IST 2006: 0 threads sync_waiting for /images/flash/video/BloomBerg.jpg, 1 still active in mongrel. Tue Sep 05 05:31:36 IST 2006: 0 threads sync_waiting for /analysts/my_avatar/kurt, 1 still active in mongrel. Tue Sep 05 05:34:18 IST 2006: 0 threads sync_waiting for /forums/home, 1 still active in mongrel. Tue Sep 05 05:34:30 IST 2006: 0 threads sync_waiting for /, 1 still active in mongrel. Tue Sep 05 05:37:39 IST 2006: 0 threads sync_waiting for /price, 1 still active in mongrel. Tue Sep 05 05:40:39 IST 2006: 0 threads sync_waiting for /price, 1 still active in mongrel. I guess it looks healthy right now. On 9/5/06, Zed Shaw wrote: > > On Tue, 2006-09-05 at 05:30 +0530, hemant wrote: > > On 9/5/06, Zed Shaw wrote: > > > > > I was using killall -USR1, but in your recent post..i have seen that > > you have updated the pre-release server...and hence i update the > > mongrel gem and..i am debugging it again.. > > > > Tue Sep 05 05:03:32 IST 2006: 0 threads sync_waiting > > for /images/tab_but_normal1.png, 4 still active in mongrel. > > > > So, what does the above line mean? 4 still active in mongrel? does it > > mean that 4 threads are waiting for this file? > > > > Does it mean..that for every file that is not found...in the rails > > application directory, mongrel threads wait? > > > > It means that a request came in, it hit rails, there were 0 waiting for > rails, and there's still 4 "in mongrel". These four are probably busy > sending a response. > > What you don't want to see is: > > Tue Sep 05 05:03:32 IST 2006: 980 threads sync_waiting > for /images/tab_but_normal1.png, 975 still active in mongrel. > > Additionally, why in the world are you having Mongrel serve the files. > Please, please, please configure your apache correctly so that apache > serves the files and mongrel just does Rails. You'd be way better off > just doing that. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060905/6d46ee53/attachment-0001.html From jaredbrown at gmail.com Mon Sep 4 22:07:35 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Mon, 4 Sep 2006 22:07:35 -0400 Subject: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- Docs and more Docs In-Reply-To: <1157339129.6093.1.camel@localhost.localdomain> References: <1157312074.10409.40.camel@localhost.localdomain> <1157318779.11883.2.camel@localhost.localdomain> <1157339129.6093.1.camel@localhost.localdomain> Message-ID: Awesome, thank you for all your hard work! On 9/3/06, Zed Shaw wrote: > > On Sun, 2006-09-03 at 17:44 -0400, Jared Brown wrote: > > Any estimate on when the next version of mongrel_clusters going to be > > ready for primetime? > > > > Should be ready now. It's now part of the regular Mongrel builds so you > can just get it the same way you get the mongrel pre-release. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060904/8f2facde/attachment.html From gethemant at gmail.com Tue Sep 5 01:37:40 2006 From: gethemant at gmail.com (hemant) Date: Tue, 5 Sep 2006 11:07:40 +0530 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: References: <1157413171.6217.12.camel@localhost.localdomain> <1157414917.6353.2.camel@localhost.localdomain> Message-ID: What these warnings mean: /usr/local/lib/site_ruby/1.8/transaction/simple.rb:74: warning: already initialized constant Messages /usr/local/lib/site_ruby/1.8/transaction/simple.rb:274: warning: already initialized constant TRANSACTION_SIMPLE_VERSION /usr/local/lib/site_ruby/1.8/transaction/simple.rb:635: warning: already initialized constant TRANSACTION_CHECKPOINT /usr/local/lib/site_ruby/1.8/transaction/simple.rb:636: warning: already initialized constant SKIP_TRANSACTION_VARS Earlier...i had a model called Message, so i thought I was getting these warnings because...but even after getting rid of that model..i get those errors. Still...i guess, it could be a problem at my end....but just wanted to put it up here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060905/6805edac/attachment.html From krisleech at interkonect.com Tue Sep 5 03:44:26 2006 From: krisleech at interkonect.com (Kris Leech) Date: Tue, 05 Sep 2006 08:44:26 +0100 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> <44FBFC9B.7050600@interkonect.com> <44FC0317.5070707@supercool.nl> Message-ID: <44FD2ADA.3030902@interkonect.com> Vishnu Gopal wrote: >mongrel_cluster is installed with the mongrel gem and makes it easy to >serve multiple mongrel instances. > >`mongrel_rails cluster::configure -h` for help. > > Ummmm.... An earlier poster said mongrel_rails is mod_proxy_balancer, I thought the mod_* where compiled code, that about looks like ruby code? > >On 9/4/06, Jeroen Houben wrote: > > >>Kris Leech wrote: >> >> >>>Jeroen Houben wrote: >>> >>> >>> >>> >>>>Kris Leech wrote: >>>> >>>> >>>> >>>> >>>> >>>>>A couple of questions please: >>>>> >>>>>What is the benefit of having more than one Mongrel/Rails instance on >>>>>the same machine, could one instance not serve as many requests as say >>>>>three instances? >>>>> >>>>>Is Mongrel Cluster a Apache add-in (like mod_*) or a separately running >>>>>load balancer which runs on a separate port, I could not work it out >>>>> >>>>> >>>>> >>>>>from the sample Apache config... >>>> >>>> >>>> >>>>>|# Redirect all non-static requests to cluster >>>>> RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f >>>>> RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] >>>>> >>>>>How does ||balancer://mongrel_cluster |work? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>My understanding is that one mongrel can only handle one request at a >>>>time. Therefore 3 mongrel can process 3 request simultaniously. >>>> >>>> >>>> >>>> >>>> >>>I see, and this is because Mongrel is not threaded, so its kind of like >>>replicating threads by using whole instances. >>> >>> >>> >>Well I'm not entirely sure about that. I think mongrel can do threads >>but you really shouldn't use Rails with threads. >>http://david.planetargon.us/articles/2006/08/08/why-you-need-multiple-mongrel-instances-with-rails >> >> >>>>The balancer is a module for apache >= 2.1 >>>>the balancer itself is not a seperate process, the pack of mongrels of >>>>course are seperate processes. >>>> >>>> >>>> >>>> >>>> >>>Thanks, does it replace mod_proxy_balance? >>> >>> >>> >>> >>No balancer://mongrel_cluster *is* mod_proxy_balancer, please look at >>http://mongrel.rubyforge.org/docs/apache.html for more details. >> >>Jeroen >> >>_______________________________________________ >>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 krisleech at interkonect.com Tue Sep 5 03:46:40 2006 From: krisleech at interkonect.com (Kris Leech) Date: Tue, 05 Sep 2006 08:46:40 +0100 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> <44FBFC9B.7050600@interkonect.com> Message-ID: <44FD2B60.5050702@interkonect.com> hemant wrote: > Somebody asked similar question earlier i guess...why run multiple > instances of mongrel..when it is threaded? > The simple answer is...ruby threads are not native threads.And > hence..all the ruby threads are running your current interpretor. So Mongrel is threaded but can't process concurrent requests so requires multiple instances... Am I getting that right? > > Also, if you have multi-core CPUs..you won't be able to take advantage > of that with single mongrel process..even though it is threaded and > hence in production mode....you should run 8 to 10 mongrel servers( as > per official documentation,but depends upon your hardware and hit rate) > > Again..i could be wrong..but thats my humble opinion. > > On 9/4/06, *Kirk Haines* > wrote: > > On 9/4/06, Kris Leech > wrote: > > Jeroen Houben wrote: > > > >My understanding is that one mongrel can only handle one > request at a > > >time. Therefore 3 mongrel can process 3 request simultaniously. > > > > > > > > I see, and this is because Mongrel is not threaded, so its kind > of like > > replicating threads by using whole instances. > > Mongrel is threaded. It will create a new thread for each > connection. > However, Rails does bad, unfriendly things when one tries to run > multiple threads of it at the same time. So the Mongrel handler for > Rails synchronizes Rails calls so that only one runs at a time. Thus, > to handle simultaneous Rails requests with Mongrel one needs more > than > one Mongrel process. > > > Kirk Haines > > > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > -- > nothing much to talk > >------------------------------------------------------------------------ > >_______________________________________________ >Mongrel-users mailing list >Mongrel-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/mongrel-users > From jarkko at jlaine.net Tue Sep 5 04:11:17 2006 From: jarkko at jlaine.net (Jarkko Laine) Date: Tue, 5 Sep 2006 11:11:17 +0300 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: <44FD2ADA.3030902@interkonect.com> References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> <44FBFC9B.7050600@interkonect.com> <44FC0317.5070707@supercool.nl> <44FD2ADA.3030902@interkonect.com> Message-ID: On 5.9.2006, at 10.44, Kris Leech wrote: > Vishnu Gopal wrote: > >> mongrel_cluster is installed with the mongrel gem and makes it >> easy to >> serve multiple mongrel instances. >> >> `mongrel_rails cluster::configure -h` for help. >> >> > > Ummmm.... An earlier poster said mongrel_rails is mod_proxy_balancer, No, he didn't. He said the part of apache config file you listed was mod_proxy_balancer. The latter balances requests between multiple mongrels that just listen to a high port. mongrel_cluster just sets up a cluster of multiple mongrels with a single command. You still need something to proxy the http requests from port 80 to these mongrels. That something could be a load balancer (e.g. pound) or a web server capable of proxy balancing (like nginx, hopefully next version of lighty and Apache2.2 with mod_proxy_balancer). //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2363 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060905/c0aed013/attachment.bin From jarkko at jlaine.net Tue Sep 5 04:13:33 2006 From: jarkko at jlaine.net (Jarkko Laine) Date: Tue, 5 Sep 2006 11:13:33 +0300 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: <44FD2B60.5050702@interkonect.com> References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> <44FBFC9B.7050600@interkonect.com> <44FD2B60.5050702@interkonect.com> Message-ID: <6F8B5E26-578E-427B-BB80-9E54579A4568@jlaine.net> On 5.9.2006, at 10.46, Kris Leech wrote: > hemant wrote: > >> Somebody asked similar question earlier i guess...why run multiple >> instances of mongrel..when it is threaded? >> The simple answer is...ruby threads are not native threads.And >> hence..all the ruby threads are running your current interpretor. > > So Mongrel is threaded but can't process concurrent requests so > requires > multiple instances... > Am I getting that right? Yes, just like you would have multiple fcgi processes running. However, you can get away quite nicely with just one mongrel if your load is not huge and you don't serve big files with that mongrel instance. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2363 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060905/29549264/attachment.bin From wyhaines at gmail.com Tue Sep 5 04:30:21 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Tue, 5 Sep 2006 02:30:21 -0600 Subject: [Mongrel] balancer://mongrel_cluster In-Reply-To: <44FD2B60.5050702@interkonect.com> References: <44FBF57E.7000306@interkonect.com> <44FBF830.1000807@supercool.nl> <44FBFC9B.7050600@interkonect.com> <44FD2B60.5050702@interkonect.com> Message-ID: On 9/5/06, Kris Leech wrote: > hemant wrote: > > > Somebody asked similar question earlier i guess...why run multiple > > instances of mongrel..when it is threaded? > > The simple answer is...ruby threads are not native threads.And > > hence..all the ruby threads are running your current interpretor. > > So Mongrel is threaded but can't process concurrent requests so requires > multiple instances... > Am I getting that right? No. Mongrel is threaded and Mongrel can process concurrent requests. The handler for Rails is setup to not process concurrent requests, though, to avoid Rails badness. Other Mongrel handlers may be (and probably are, in general) fully capable of operating concurrently. Kirk Haines From jan.svitok at gmail.com Tue Sep 5 04:38:34 2006 From: jan.svitok at gmail.com (Jan Svitok) Date: Tue, 5 Sep 2006 10:38:34 +0200 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: References: <1157413171.6217.12.camel@localhost.localdomain> <1157414917.6353.2.camel@localhost.localdomain> Message-ID: <8d9b3d920609050138p36217284qecb2bdcc6518870e@mail.gmail.com> On 9/5/06, hemant wrote: > What these warnings mean: > > > /usr/local/lib/site_ruby/1.8/transaction/simple.rb:74: > warning: already initialized constant Messages > /usr/local/lib/site_ruby/1.8/transaction/simple.rb:274: > warning: already initialized constant TRANSACTION_SIMPLE_VERSION > /usr/local/lib/site_ruby/1.8/transaction/simple.rb:635: > warning: already initialized constant TRANSACTION_CHECKPOINT > /usr/local/lib/site_ruby/1.8/transaction/simple.rb:636: > warning: already initialized constant SKIP_TRANSACTION_VARS > > Earlier...i had a model called Message, so i thought I was getting these > warnings because...but even after getting rid of that model..i get those > errors. > Still...i guess, it could be a problem at my end....but just wanted to put > it up here. I development mode, files are reloaded upon each request. That causes redefinition of classes, and what you have seen is a side effect of the redefinition. From g.vishnu at gmail.com Tue Sep 5 07:25:32 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Tue, 5 Sep 2006 16:55:32 +0530 Subject: [Mongrel] Mongrel Tuneup Guide: Questions In-Reply-To: References: Message-ID: Since the list has been silent on this, I'll add some more of my observations to this post. I redid the test using my dev Mac mini as a guide. It's a dual core machine, and here's what the results looked like: The numbers again are the 10sec --nconns and the final --rate 1 Mongrel serving a test /test (w/o db access, very simple page): 1600 160 4 Mongrels serving a /test: 1400 190 1 Mongrel serving a full /index: 200 18 2 Mongrels serving a full /index: 190 26 Right, and so on (didn't bother to test this further) The lesson learnt is that CPU loads become a factor very quickly with mongrels and lots of hits on the server, esp if the CPU is paltry. I'm not sure what kind of configuration all the rest of the tests I've found on the net have been run on [aah here is one: http://blog.kovyrin.net/2006/08/28/ruby-performance-results/ run on a 4x xeon with 4g ram :-)] but imho you still need a fast (much faster) web server even on a single node to run rails/mongrel as compared to php. Going the php way with very cheap machines is probably not going to work. The question I'm most interested in, and which I'd really like an answer to is that I decided on Mongrel because of the HTTP stack used throughout. I could basically have a load balancer hitting mongrels on multiple machines... very flexible stuff and not possible with the traditional fastcgi model. If I do buy more (how many?) cheap machines serving 7req/s each, and then load balance all of em (say with hardware), could I realistically hope to hit comfy loads like 300 req/s? And will this continue to scale? Or should I just buy two 4x xeons and be done with it? Again, a sample from my last 2mongrels/index logs: Completed in 0.03958 (25 reqs/sec) | Rendering: 0.02801 (70%) | DB: 0.00585 (14%) | 200 OK Vish On 9/4/06, Vishnu Gopal wrote: > Hi! > > I've been following the new mongrel tuneup guide (a huge thanks for > that btw) and here are my results. I've basically only gotten to the > point where I'm tuning up 1 mongrel because I suspect I have a > performance problem with my rails app. > > http://mongrel.rubyforge.org/docs/how_many_mongrels.html > The first number is the 10s nconns and the second is the max req/s as > per the guide: > > Lighttpd serving static files: > 6000 1800 > 1 Mongrel serving static files: > 2800 200 > 1 Mongrel serving a bare /login page (without db query, no layout, > just an action): > 750 50 > 1 Mongrel serving my full /index page (many db queries, render with layout) > 80 7 > > Right, so I guess my "rails measurement is horribly slow". The thing > is, I've worked on the /index page a lot. I've implemented memcached, > so db queries are basically minimal, and so the bottlneck basically is > like this: > > The index page doesn't have any components, just 1 partial (called 2 times). > > logs (in debug mode) look like this (for /index): > Completed in 0.21839 (4 reqs/sec) | Rendering: 0.16793 (76%) | DB: 0.02759 (12%) > > What do I do to optimize this situation? Think I'm missing something here... > > P.S. I'm running FreeBSD on a Celeron 2.0Ghz/2GB ram. And my processer > is at 100% peak mostly when I'm hitting the load. > > Vish > From wyhaines at gmail.com Tue Sep 5 10:46:12 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Tue, 5 Sep 2006 08:46:12 -0600 Subject: [Mongrel] Simple Mongrel performance question Message-ID: Zed, Do you have a feeling for how Mongrel's speed has changed since you started out? Just Mongrel with a plain static file; not burdened with having to go through Rails. You initial numbers were substantially faster than webrick. Now that there is a lot more stuff in Mongrel, are they still substantially faster in your benchmarks? Thanks, Kirk Haines From steven at lumos.us Tue Sep 5 13:13:08 2006 From: steven at lumos.us (Steven Lumos) Date: Tue, 05 Sep 2006 10:13:08 -0700 Subject: [Mongrel] Recommentation: Sessions and PStore References: <1157300286.6020.50.camel@localhost.localdomain> <1157304031.10409.0.camel@localhost.localdomain> <1157308440.10409.27.camel@localhost.localdomain> Message-ID: <86psea5ja3.fsf@bitty.lumos.us> Zed Shaw writes: > On Sun, 2006-09-03 at 11:48 -0600, Kirk Haines wrote: >> On 9/3/06, Zed Shaw wrote: >> >> > Theorize all you want, but all I know is, use Mutex, process gets >> > killed, use Sync, process stays up. Can't argue with the evidence. >> >> Sure I can. Your conclusion about Mutex is like the conclusion once >> drawn about the sun. It comes up in the east and goes down in the >> west, so the evidence clearly shows that the sun rotates around the >> earth, right? >> >> There is nothing wrong with Mutex. It's an incredibly simple piece of >> code and can quite clearly be demonstrated not to leak. >> >> I'm not arguing with the fact that for some users simply swapping Sync >> in place of Mutex appears to clear a problem. I'm just arguing with >> your conclusion that this is because Mutex is broken or because Ruby >> is leaking memory when it is used. > > I like you Kirk, so don't take it personally, it's just an incredibly > sore spot with me since I've been complaining about this for ages and > everyone keeps telling me I'm crazy despite what I demonstrate. > > But, explain this: > > http://pastie.caboo.se/10194 > > > vs. > > http://pastie.caboo.se/10317 > > First one leaks, second one doesn't (with graphs even). What's worse is > the inverse is true on win32. These scripts have no Mongrel code, no > Rails code, they're just short Ruby scripts. I'm really not trying to be dense here, but why are you reading a horizontal line as a leak? Especially a horizontal line that is not very far above the average ('estimated' by squinting and guessing) of the second graph.... Steve From jacob at jacobatzen.dk Tue Sep 5 13:58:32 2006 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Tue, 5 Sep 2006 19:58:32 +0200 Subject: [Mongrel] Mongrel Tuneup Guide: Questions In-Reply-To: References: Message-ID: <20060905175831.GA10931@nezbo.dhcp.aub.dk> On Mon, Sep 04, 2006 at 07:00:25PM +0530, Vishnu Gopal wrote: > Right, so I guess my "rails measurement is horribly slow". The thing > is, I've worked on the /index page a lot. I've implemented memcached, > so db queries are basically minimal, and so the bottlneck basically is > like this: > > The index page doesn't have any components, just 1 partial (called 2 times). > > logs (in debug mode) look like this (for /index): > Completed in 0.21839 (4 reqs/sec) | Rendering: 0.16793 (76%) | DB: 0.02759 (12%) > > What do I do to optimize this situation? Think I'm missing something here... What does your logfiles tell you about the rendering of parts of your index page? Are you using fragment caching or index caching or page caching? I would assume your index page could be page cached and served directly from Apache or whatever frontend you're using for mongrel. Not sure why you're seeing so long render times though. Perhaps your logs can reveal more. -- Cheers, - Jacob Atzen From al-mongrelusers at none.at Tue Sep 5 13:58:59 2006 From: al-mongrelusers at none.at (Alexander Lazic) Date: Tue, 5 Sep 2006 19:58:59 +0200 Subject: [Mongrel] Mongrel Tuneup Guide: Questions In-Reply-To: References: Message-ID: <20060905175859.GA19165@none.at> On Die 05.09.2006 16:55, Vishnu Gopal wrote: > >The numbers again are the 10sec --nconns and the final --rate > >1 Mongrel serving a test /test (w/o db access, very simple page): >1600 160 > >4 Mongrels serving a /test: >1400 190 > >1 Mongrel serving a full /index: >200 18 > >2 Mongrels serving a full /index: >190 26 2 Mongrels are slower for the w/o pages, are you sure?! >Right, and so on (didn't bother to test this further) > >The lesson learnt is that CPU loads become a factor very quickly with >mongrels and lots of hits on the server, esp if the CPU is paltry. As i have seen that's also true for java/perl/... $appservers ;-) >I'm not sure what kind of configuration all the rest of the tests I've >found on the net have been run on [aah here is one: >http://blog.kovyrin.net/2006/08/28/ruby-performance-results/ run on a >4x xeon with 4g ram :-)] but imho you still need a fast (much faster) >web server even on a single node to run rails/mongrel as compared to >php. Going the php way with very cheap machines is probably not going >to work. I think the nginx and lighttpd could be fast enought, could you share your setup so that we can look a little bit behind the scene ;-) >If I do buy more (how many?) cheap machines serving 7req/s each, and >then load balance all of em (say with hardware), could I realistically >hope to hit comfy loads like 300 req/s? And will this continue to >scale? 42 maschines, isn't it this too much?! How about to look into the app to get mor req/s?! Regards Alex From luislavena at gmail.com Tue Sep 5 16:50:47 2006 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 5 Sep 2006 17:50:47 -0300 Subject: [Mongrel] The real reason why Sync and Mutex behave differently In-Reply-To: References: Message-ID: <71166b3b0609051350obf264ecv64c118f5f4c1d7ac@mail.gmail.com> Kirk, After reading your analysis, I'm interested in the custom, compiled solution you're talking about. Anyway, the use of thread.critical isn't a viable locking method, as said by ruby-core by matz a few years back (1.6 version I think). The really funny part is that, based on your interpretation of the problem, why the GC of both platforms behave differently? I know that ruby GC isn't the fastest, nor the optimal (nor even as good as other, simplistic GC around the net). The whole mark and sweep method is too "intensive". But, why the differences between platforms? even as you said what do Mutex and what do Sync... ruby-mswin32 (stable from official build, vc6) do garbage collect of Mutex when linux doesn't? On 9/4/06, Kirk Haines wrote: > As I've mentioned before, Sync and Mutex are very similar, and Mutex > is very simple. > > Their locking algorithm (for exclusive locking) is essentially identical. > > And in some detailed examinations of Mutex's behavior, there's nothing > superficially wrong with it. It's pure ruby, so there are no funny > memory allocations at the C level, and it essentially operates by > using an array as a queue for waiting threads. Very little is > involved. > > Sync does a bunch of other things, since it supports shared locking in > addition to exclusive, so it is much more complicated. However, the > main difference between them, when one is using exclusive locking, is > in the way they perform unlocking. > > Mutex: > > Thread.critical = true > @locked = false > begin > t = @waiting.shift > t.wakeup if t > rescue ThreadError > retry > end > Thread.critical = false > begin > t.run if t > rescue ThreadError > end > self > > With Mutex, the next thread to unlock is shifted off the beginning of the array. > > With Sync, there is one key difference: > > wait = sync_waiting > self.sync_waiting = [] > Thread.critical = false > for w in wait > w.run > end > > With Sync, a copy is made of the array or waiting threads, the waiting > thread queue is set to a fresh, empty array, and all of the threads > pointed to in the copy are woken up. One will get the lock, and the > rest insert themselves back into the waiting queue. > > That copy of the sync_waiting array, "wait", which is now the only > thing pointing at the original array, then gets thrown away, letting > it get garbage collected. > > That's the key to the difference, right there. > > With Mutex, the shift operation reduces the size of the array, but > shift never reallocs. > With Sync, that array gets thrown away, and when gc runs, it is > cleaned up. This whole thing with Mutex hinges on the memory > management behavior in array.c. This is why throwing away the mutex > and creating a new one between iterations in that test script produces > a result similar to what Sync produces, too, as the net effect is that > the array that the mutex uses to track threads gets thrown away. > > I made a copy of Mutex and changed it to use a linked list instead of > an array to queue waiting threads, thereby eliminating array.c from > the mix while keeping the rest of Mutex.rb intact, and I now get > completely perfect, deterministic behavior on both Linux and Win XP. > > array.c's behavior is what needs to be examined in greater detail, here. > > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From wyhaines at gmail.com Tue Sep 5 17:20:56 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Tue, 5 Sep 2006 15:20:56 -0600 Subject: [Mongrel] The real reason why Sync and Mutex behave differently In-Reply-To: <71166b3b0609051350obf264ecv64c118f5f4c1d7ac@mail.gmail.com> References: <71166b3b0609051350obf264ecv64c118f5f4c1d7ac@mail.gmail.com> Message-ID: On 9/5/06, Luis Lavena wrote: > Anyway, the use of thread.critical isn't a viable locking method, as > said by ruby-core by matz a few years back (1.6 version I think). Thread.critical alone makes it easy to get oneself into trouble, but both Sync and Mutex are built on top of it. > The really funny part is that, based on your interpretation of the > problem, why the GC of both platforms behave differently? I think the differences observed between Linux and WinXP relate to how each platform's memory management interacts with Ruby. BTW, although switching Mutex to using a linked list for the thread queue worked great, it appears that one can get Ruby to do reasonable things with the array by switching the push in lock and the shift in unlock to be an unshift and a pop, respectively. This is because pop will realloc the array. I haven't yet tested that as extensively as I did the mutex with linked list, but so far it appears solid. > I know that ruby GC isn't the fastest, nor the optimal (nor even as > good as other, simplistic GC around the net). The whole mark and sweep > method is too "intensive". > > But, why the differences between platforms? even as you said what do > Mutex and what do Sync... ruby-mswin32 (stable from official build, > vc6) do garbage collect of Mutex when linux doesn't? That really just looks like a difference in platform memory management interaction with Ruby. The fixes (linked list or changing array operations) both appear to work identially on Linux and WinXP, though, without incurring the speed penalty that Sync has. I'm doing more testing this week, though, on both Linux and WinXP. I'll send out updates here and on ruby-talk if I find anything else that is useful or interesting. Kirk From random49k at gmail.com Tue Sep 5 17:32:41 2006 From: random49k at gmail.com (Mike Garey) Date: Tue, 5 Sep 2006 17:32:41 -0400 Subject: [Mongrel] Mongrel and umask for uploaded files Message-ID: <16a8b9140609051432s29c9fc6fsd78113ceb57f7665@mail.gmail.com> So any files that are uploaded through my form are getting the following mode: -rw------- I need them to have: -rw-r--r-- I've tried setting the umask in a script file called set_umask.rb as follows: File.umask(022) and then starting mongrel using: mongrel_rails start -m config/mime.types -S set_umask.rb but it doesn't seem to change the mode that the files are created with.. I've also tried putting "File.umask(022)' inside environment.rb but that doesn't make a difference. To handle uploads, I have a resource model which does the following in the before_create filter: def before_create return FileUtils.copy( @uploaded_file.local_path, self.path_to_file) if @uploaded_file.instance_of?(Tempfile) # else File.open(self.path_to_file, "w") { |f| f.write(@uploaded_file.read) } end If anyone has any other hints for how to change the umask, please let me know, this is driving me crazy! Thanks, Mike From ian at blenke.com Tue Sep 5 17:57:14 2006 From: ian at blenke.com (Ian C. Blenke) Date: Tue, 05 Sep 2006 17:57:14 -0400 Subject: [Mongrel] Undefined class/module error: solved? Message-ID: <44FDF2BA.8080709@blenke.com> The Problem ----------- We have been getting a "undefined class/module" error on 2 of our 6 app servers in one testbed. Same sourcecode, same installs (systemimager and an isconf style configuration management harness), same binaries. Identical everything. Pound + mongrel + memcached + postgres (pgcluster). The odd bit here is that our "dev" and "prod" pairs had one node reporting the error, but the other node did not. The "qa" pair worked just fine with both app servers, without incident. Jason Hall reported the same thing on IRC, and we compared notes. Basically, the problem looks identical to this unanswered RubyForge error: http://rubyforge.org/tracker/index.php?func=detail&aid=3419&group_id=1266&atid=4982 Here is a snippet from the logs where I was seeing the problem: /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/command.rb:199:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:235 /usr/bin/mongrel_rails:18 undefined class/module Project /usr/lib/ruby/gems/1.8/gems/memcache-client-1.0.3/lib/memcache.rb:128:in `get' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/memcache-client-1.0.3/lib/memcache.rb:98:in `get' All of them identical. An error restoring an object from a memcached session. I caught Zed online and asked about it, he suggested removing any "complex datatypes from the session". I was going this direction when Jason Hall found a "solution": The Solution ----------- Jason Hall found a workaround: merely add a "model" line to the app/controller/application.rb, and those model :user, :group, :project From what I've been told, "model" is deprecated in Edge Rails, so this isn't a permanent solution. But this does make for an interim workaround. I guess my question is: why would a class be undefined? Is this some kind of a loadpath issue? - Ian C. Blenke http://ian.blenke.com/ From zedshaw at zedshaw.com Tue Sep 5 18:05:00 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Tue, 05 Sep 2006 15:05:00 -0700 Subject: [Mongrel] Mongrel Tuneup Guide: Questions In-Reply-To: References: Message-ID: <1157493900.6097.37.camel@localhost.localdomain> On Tue, 2006-09-05 at 16:55 +0530, Vishnu Gopal wrote: > Since the list has been silent on this, I'll add some more of my > observations to this post. > > I redid the test using my dev Mac mini as a guide. It's a dual core > machine, and here's what the results looked like: > > The numbers again are the 10sec --nconns and the final --rate > > 1 Mongrel serving a test /test (w/o db access, very simple page): > 1600 160 > > 4 Mongrels serving a /test: > 1400 190 > > 1 Mongrel serving a full /index: > 200 18 > > 2 Mongrels serving a full /index: > 190 26 > Hmm, I'd question either how you measured or how you have things configured. Take a look at your system stats, try moving mysql out, change it up a bit and see what the optimal configuration is with just 2 mongrels. I'm suspecting there's something else going on since those results are contrary to what I've seen. Now, what you've done is correct and it's showing you the limits of your configuration. First, the best you can do is 160 req/sec. Second, your typical page will get around 26 req/sec. Now, whether this is enough for you depends on your application. One question though, did you run httperf on the same machine as the one you're testing? httperf will use the CPU pretty heavily when it's doing a good test, so you'll need to use a laptop connected to the same switch/router as your server. Also, MySQL is a memory hog, which impacts Mongrel quite a bit. > The lesson learnt is that CPU loads become a factor very quickly with > mongrels and lots of hits on the server, esp if the CPU is paltry. > Yep, this also shows that you've got an index page you can make faster, but that it might be cheaper for you to just throw hardware at it (as you mention below). > I'm not sure what kind of configuration all the rest of the tests I've > found on the net have been run on [aah here is one: > http://blog.kovyrin.net/2006/08/28/ruby-performance-results/ run on a > 4x xeon with 4g ram :-)] but imho you still need a fast (much faster) > web server even on a single node to run rails/mongrel as compared to > php. Going the php way with very cheap machines is probably not going > to work. > One of the reasons I tell people to do this kind of test is for the simple reason that buying the same hardware as Ezra doesn't mean you get the same performance he does. He's got a different application, different code, probably has his database on a different server, and he might have some tricks you don't. What you need to do now is go tinkering with your configuration to see if you can get it to go faster. I think now you're at the stage where the numbers are showing your configuration isn't that great, but you need to take the next step and say, "Ok, I'm a moron, I should have this configured differently." Having these numbers then makes your task easier. You know the best that one machine can get is 160 req/sec, so you'll need at least 2. You know what your performance is for /index, so you can make changes and continue measuring to see if these changes help. Without these numbers you'd be just guessing. > The question I'm most interested in, and which I'd really like an > answer to is that I decided on Mongrel because of the HTTP stack used > throughout. I could basically have a load balancer hitting mongrels on > multiple machines... very flexible stuff and not possible with the > traditional fastcgi model. > > If I do buy more (how many?) cheap machines serving 7req/s each, and > then load balance all of em (say with hardware), could I realistically > hope to hit comfy loads like 300 req/s? And will this continue to > scale? > Ok, yes, you can do this, but where did 300 req/s come from? Did you just make that up? Is it based on user surveys of what they think of the page speed? Is it necessary for all your pages? The point of scalability is to start small then *scale* up. Not to go crazy buying billions of dollars worth of equipment to hit some made-up vanity number. Sit back for a bit and do an analysis of what the req/s of these pages actually needs to be in order to meet service goals. Then go in and try other simple tricks to see if you can make them marginally faster. For example, unless your index page changes drastically for every request you should be using page caching. If your index page *must* change for every request, then consider redesigning it so that this isn't a requirement. Stefan Kaes has lots of really good recommendations on things you can do to tune your application. Go read his stuff. But, base this tuning and your effort and expenditures on a realistic, reasonable and measurable goal. > Or should I just buy two 4x xeons and be done with it? First, double check that you did the analysis right, check your configuration and try to make it faster, then yes buy a *little* bit of hardware to run another test and see if that improves. Don't spend a million dollars on a solution that might not work. Which brings me to another point: Maybe Mongrel isn't for you. There's a bunch of contenders right now, and sometimes Mongrel's simplicity and flexibility doesn't work for people. Other folks run pretty big fast sites on Mongrel, but they understand how to tune Rails. If you're not in this camp then go check out some of the other Rails deployment options. First up would be Litespeed. It's commercial software and you'd pay per CPU, but if it gives you your 300 req/sec vanity number then spend the money there. Hope that helps. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Tue Sep 5 19:12:22 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Tue, 05 Sep 2006 16:12:22 -0700 Subject: [Mongrel] Simple Mongrel performance question In-Reply-To: References: Message-ID: <1157497942.6097.59.camel@localhost.localdomain> On Tue, 2006-09-05 at 08:46 -0600, Kirk Haines wrote: > Zed, > > Do you have a feeling for how Mongrel's speed has changed since you > started out? Just Mongrel with a plain static file; not burdened with > having to go through Rails. > > You initial numbers were substantially faster than webrick. Now that > there is a lot more stuff in Mongrel, are they still substantially > faster in your benchmarks? > Yep, actually I was just running a few little tests right now. Take a look: > summary(perfd) mngrl sside wbrick Min. :1426 Min. :1777 Min. :364.3 1st Qu.:1492 1st Qu.:3108 1st Qu.:382.4 Median :1493 Median :3164 Median :384.2 Mean :1488 Mean :3020 Mean :383.4 3rd Qu.:1494 3rd Qu.:3192 3rd Qu.:387.9 Max. :1509 Max. :3284 Max. :390.6 > sd(perfd) mngrl sside wbrick 22.618736 446.010569 7.422556 Which when you break out the standard deviations (2*sd) you get: Mongrel: 1444 to 1532 ServerSide: 2128 to 3912 Webrick: 369 to 397 (That's theoretical performance, I'm thinking serverside isn't really that erratic). You can also get all of the data I used, my RData and Rhistory, as well as graphs of the two servers performance as line and boxplots at: http://mongrel.rubyforge.org/perftest/ I'd say ServerSide is kicking some serious ass, but it's got a long way to go before it can run a rails app. It also has these problems currently: 1) Doesn't use a parser but rather a couple regular expressions to parse HTTP. This will most likely blossom into a giant set of regular expressions (which is a lot like a parser anyway), and won't have the security advantages that a parser has. 2) It loads the whole file in ram. I tried serving a ISO image and that process used 660M of ram. Mongrel streams files so it serves larger files slower, but will actually serve them without running out. 3) It seems to choke when you hit it with a lot of requests, mostly because it doesn't defend against all the various weird exceptions ruby throws when things start to go really wrong. 4) It doesn't support a lot of the gear needed to run web frameworks like handler chains, objects for processing request and response data (he rejects it directly), and a CGI wrapper. 5) Creates a monitoring process to track the other processes. Ruby's very terrible at this, whereas other tools like monit and daemontools are fantastic at this (which is why we went with a mongrel_cluster kind of thing). This also means it won't support win32 most likely. 6) Doesn't seem to perform too consistently, but it's fast enough that most people wouldn't care. It's still pretty impressive for a first run. I'd be curious to see if some kind of mongrel+severside alliance could be had, but I suspect the author has his eye on the "fastest web server" prize. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From krisleech at interkonect.com Wed Sep 6 04:21:17 2006 From: krisleech at interkonect.com (Kris Leech) Date: Wed, 06 Sep 2006 09:21:17 +0100 Subject: [Mongrel] Tracing a HTTP request/response through a scaled server deployment Message-ID: <44FE84FD.5050805@interkonect.com> Would anybody be interested in tracing a HTTP request/response through a typical Rails scaled server deployment? I already posted something similar on the rails list but the post appears to have disappeared... I am happy to write it up if I can get help at certain stages, I thinking something like this while might not particualy help people on this this list, since you are most likely familiar with deployment, but it would be useful to the Rails community in general since deployment is the bottleneck for Rails (IMHO). I think a lot of people are not used to dealing with HTTP, proxies etc. once it gets beyond a simple webrick deploy. I would like to cover the web server (+ virtual hosts), proxy and the application servers and dispatcher. Anything else that I should add? Thanks, K. From kraemer at webit.de Wed Sep 6 04:25:21 2006 From: kraemer at webit.de (Jens Kraemer) Date: Wed, 6 Sep 2006 10:25:21 +0200 Subject: [Mongrel] Mongrel and umask for uploaded files In-Reply-To: <16a8b9140609051432s29c9fc6fsd78113ceb57f7665@mail.gmail.com> References: <16a8b9140609051432s29c9fc6fsd78113ceb57f7665@mail.gmail.com> Message-ID: <20060906082521.GX9513@cordoba.webit.de> Hi! On Tue, Sep 05, 2006 at 05:32:41PM -0400, Mike Garey wrote: > So any files that are uploaded through my form are getting the following mode: > > -rw------- > > I need them to have: > > -rw-r--r-- > > I've tried setting the umask in a script file called set_umask.rb as follows: > > File.umask(022) > > and then starting mongrel using: > > mongrel_rails start -m config/mime.types -S set_umask.rb > > but it doesn't seem to change the mode that the files are created > with.. I've also tried putting "File.umask(022)' inside > environment.rb but that doesn't make a difference. I've had similar problems, in my case the umask I set was used when uploading from Firefox/linux, but not when uploading from Firefox/windows. Weird, but manually changing the permissions after copying the file finally fixed this. File.chmod(0644, self.path_to_file) after the File.open line should do the trick for you. Jens > > To handle uploads, I have a resource model which does the following in > the before_create filter: > > def before_create > return FileUtils.copy( @uploaded_file.local_path, > self.path_to_file) if @uploaded_file.instance_of?(Tempfile) > # else > File.open(self.path_to_file, "w") { |f| f.write(@uploaded_file.read) } > end > > > If anyone has any other hints for how to change the umask, please let > me know, this is driving me crazy! Thanks, > > Mike > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users -- webit! Gesellschaft f?r neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de Schnorrstra?e 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66 From kris at alternativefocusmedia.com Wed Sep 6 09:42:47 2006 From: kris at alternativefocusmedia.com (Kris Leech) Date: Wed, 06 Sep 2006 14:42:47 +0100 Subject: [Mongrel] Error on Windows and FreeBSD Message-ID: <44FED057.9030001@alternativefocusmedia.com> First off Windows, because actually what I appear to be getting is a Rails error which only occurs when I use Mongrel, using Webrick I do not get this error. I start Mongrel using: mongrel_rails start I have mongrel, win32-services and mongrel-service gems installed even through Im not using mongrel as a service at the moment. The whole application works apart from one action. The error I get is: NoMethodError in SearchController#results undefined method `table_name' for Stop:Class |(__DELEGATION__):2:in `__send__' (__DELEGATION__):2:in `table_name' #{RAILS_ROOT}/app/models/search.rb:58:in `find_runs' #{RAILS_ROOT}/app/models/search.rb:44:in `depature_runs' #{RAILS_ROOT}/app/controllers/search_controller.rb:100:in `results'| So my results action gives an error for table_name! The Stop model is used by various other controllers just fine. In Console I can do Stop.find_all, so I dont see how this error is being generated, besides the application server, mongrel, webrick or other, should not have any effect once it palms the request off to dispatcher? Many thanks AFM. PS. The freeBSD error can wait for another time :) From wconrad at yagni.com Wed Sep 6 15:13:53 2006 From: wconrad at yagni.com (Wayne Conrad) Date: Wed, 6 Sep 2006 12:13:53 -0700 Subject: [Mongrel] Running multiple clusters In-Reply-To: References: Message-ID: <20060906191350.GA17894@yagni.com> On Sun, Sep 03, 2006 at 04:28:38PM -0400, Jared Brown wrote: > I want to run two or more clusters for my rails application so that I can do > a seamless update and not suffer any downtime. > But I don't understand how to setup two clusters since there is only one > mongrel config file. > How would I go about doing this? Jared, See http://mongrel.rubyforge.org/docs/mongrel_cluster.html Read the section "ON BOOT INITIALIZATION SETUP". You'll end up with a /etc/mongrel_cluster directory containing one configuration file for each cluster that you want started when the system boots. Does that help? Did I answer the question you were actually asking? I hope so. Wayne Conrad From luislavena at gmail.com Wed Sep 6 15:36:43 2006 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 6 Sep 2006 16:36:43 -0300 Subject: [Mongrel] Error on Windows and FreeBSD In-Reply-To: <44FED057.9030001@alternativefocusmedia.com> References: <44FED057.9030001@alternativefocusmedia.com> Message-ID: <71166b3b0609061236l737c68d1r4f1c79a7f3a37cc1@mail.gmail.com> Wow, that's nasty. What version of mongrel gem are you using? Also, you said on Windows, but which one? What ruby distro are you using? (hope mswin32 of 1.8.4 which is based on VC6, same for One-Click Installer). It is only thrown apart when calling that method? which code contains? (please paste for better understanding of what are you doing that brake so badly). On 9/6/06, Kris Leech wrote: > First off Windows, because actually what I appear to be getting is a > Rails error which only occurs when I use Mongrel, using Webrick I do not > get this error. > I start Mongrel using: > mongrel_rails start > > I have mongrel, win32-services and mongrel-service gems installed even > through Im not using mongrel as a service at the moment. > > The whole application works apart from one action. The error I get is: > > > NoMethodError in SearchController#results > > undefined method `table_name' for Stop:Class > > |(__DELEGATION__):2:in `__send__' > (__DELEGATION__):2:in `table_name' > #{RAILS_ROOT}/app/models/search.rb:58:in `find_runs' > #{RAILS_ROOT}/app/models/search.rb:44:in `depature_runs' > #{RAILS_ROOT}/app/controllers/search_controller.rb:100:in `results'| > > > So my results action gives an error for table_name! The Stop model is > used by various other controllers just fine. In Console I can do > Stop.find_all, so I dont see how this error is being generated, > besides the application server, mongrel, webrick or other, should not > have any effect once it palms the request off to dispatcher? > > > Many thanks AFM. > > PS. The freeBSD error can wait for another time :) > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From zedshaw at zedshaw.com Wed Sep 6 16:24:19 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 06 Sep 2006 13:24:19 -0700 Subject: [Mongrel] Error on Windows and FreeBSD In-Reply-To: <44FED057.9030001@alternativefocusmedia.com> References: <44FED057.9030001@alternativefocusmedia.com> Message-ID: <1157574259.8504.4.camel@localhost.localdomain> On Wed, 2006-09-06 at 14:42 +0100, Kris Leech wrote: > First off Windows, because actually what I appear to be getting is a > Rails error which only occurs when I use Mongrel, using Webrick I do not > get this error. > I start Mongrel using: > mongrel_rails start > > I have mongrel, win32-services and mongrel-service gems installed even > through Im not using mongrel as a service at the moment. > > The whole application works apart from one action. The error I get is: > > > NoMethodError in SearchController#results > > undefined method `table_name' for Stop:Class Mongrel already has created a class called "Stop", so your class is conflicting with it. Basically, Stop, Start, Restart, are all classes in mongrel to make the commands work. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From Daniel.Berger at qwest.com Wed Sep 6 16:56:01 2006 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Wed, 6 Sep 2006 15:56:01 -0500 Subject: [Mongrel] Error on Windows and FreeBSD Message-ID: <39AA6550E5AA554AB1456707D6E5563D0259E7FC@QTOMAE2K3M01.AD.QINTRA.COM> > From: mongrel-users-bounces at rubyforge.org > [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed Shaw > Sent: Wednesday, September 06, 2006 2:24 PM > To: mongrel-users at rubyforge.org > Subject: Re: [Mongrel] Error on Windows and FreeBSD > > > On Wed, 2006-09-06 at 14:42 +0100, Kris Leech wrote: > > First off Windows, because actually what I appear to be getting is a > > Rails error which only occurs when I use Mongrel, using > Webrick I do not > > get this error. > > I start Mongrel using: > > mongrel_rails start > > > > I have mongrel, win32-services and mongrel-service gems > installed even > > through Im not using mongrel as a service at the moment. > > > > The whole application works apart from one action. The > error I get is: > > > > > > NoMethodError in SearchController#results > > > > undefined method `table_name' for Stop:Class > > Mongrel already has created a class called "Stop", so your > class is conflicting with it. > > Basically, Stop, Start, Restart, are all classes in mongrel > to make the commands work. Are these classes not wrapped in a 'Mongrel' module? If not, it might be worth considering. If so, well, nevermind then. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From kigsteronline at mac.com Wed Sep 6 18:15:29 2006 From: kigsteronline at mac.com (kigsteronline at mac.com) Date: Wed, 6 Sep 2006 15:15:29 -0700 Subject: [Mongrel] Error on Windows and FreeBSD In-Reply-To: <1157574259.8504.4.camel@localhost.localdomain> References: <44FED057.9030001@alternativefocusmedia.com> <1157574259.8504.4.camel@localhost.localdomain> Message-ID: <89B2F93C-4480-45C5-8298-9E4E7AD7FF4D@mac.com> Actually this naming problem is one of the hard-to-bite problems that hit everyone new and old to Ruby. We were recently hit by another couple of those name clashes: turns out you can not name your model attribute "binding" (this was appropriate for the model "Book"), nor can you use an attribute called "target" in your model. The unfortunate name collision problem is very hard to detect. The binding attribute/method was conflicting with Proc.binding and throwing error deep down ActiveRecord stack. If anyone knows a good approach to resolving name conflicts, or at least testing whether an issue being diagnosed may be a result of a name clash, please share. Thanks Konstantin On Sep 6, 2006, at 1:24 PM, Zed Shaw wrote: > On Wed, 2006-09-06 at 14:42 +0100, Kris Leech wrote: >> First off Windows, because actually what I appear to be getting is a >> Rails error which only occurs when I use Mongrel, using Webrick I >> do not >> get this error. >> I start Mongrel using: >> mongrel_rails start >> >> I have mongrel, win32-services and mongrel-service gems installed >> even >> through Im not using mongrel as a service at the moment. >> >> The whole application works apart from one action. The error I get >> is: >> >> >> NoMethodError in SearchController#results >> >> undefined method `table_name' for Stop:Class > > Mongrel already has created a class called "Stop", so your class is > conflicting with it. > > Basically, Stop, Start, Restart, are all classes in mongrel to make > the > commands work. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > 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/20060906/ab6d62ae/attachment.html From john at fivesquaresoftware.com Wed Sep 6 19:02:08 2006 From: john at fivesquaresoftware.com (John Clayton) Date: Wed, 6 Sep 2006 16:02:08 -0700 Subject: [Mongrel] Running multiple domains on one codebase, mongrel a good choice? Message-ID: We're working on rails application for a client that needs to be deployed under a variety of domain names and needs the ability to load custom configurations for the database, parts of the docroot, caching, etc. based on the site we're serving. We use mongrel to host some other single domain apps and would like to do so here too. We'd like to not have to deploy the codebase multiple times either (since it's identical) so we're trying to figure out a way maybe to load each instance into mongrel with different params and then let the instance configure itself. Does anyone have experience using mongrel in this way or similar? Thanks, John From wyhaines at gmail.com Wed Sep 6 21:11:49 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 6 Sep 2006 19:11:49 -0600 Subject: [Mongrel] IOWA & Mongrel, performance Message-ID: So, after far too long, I'm running successful tests of an IOWA/Mongrel integration. This is using Mongrel 0.3.13.3. I created an app that is the same as the one tested here: http://blog.kovyrin.net/2006/08/28/ruby-performance-results/ Just running a single mongrel on an AMD Athlon (2 Ghz) dual processor system with a Linux 2.4 kernel and Ruby 1.8.4 I get, with a concurrency of 1, around 345 requests per second. Higher concurrencies remain manageable, though, which is nice to see. I get around 270/second with a concurrency of 100, for instance. This is reasonably fast. For comparison, going through Apache 2 with a mod_ruby handler, I get 240/second with a concurrency of 1, and it peaks at around 370/second with a concurrency of 3 before going down. Apache was floundering with a concurrency of 100 so I aborted that test. This is running in prefork mode, BTW. So....not bad at all! Kirk Haines From luislavena at gmail.com Wed Sep 6 21:40:41 2006 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 6 Sep 2006 22:40:41 -0300 Subject: [Mongrel] Running multiple domains on one codebase, mongrel a good choice? In-Reply-To: References: Message-ID: <71166b3b0609061840t6b387842kcb6c8d48c0b49357@mail.gmail.com> On 9/6/06, John Clayton wrote: > We're working on rails application for a client that needs to be > deployed under a variety of domain names and needs the ability to > load custom configurations for the database, parts of the docroot, > caching, etc. based on the site we're serving. We use mongrel to > host some other single domain apps and would like to do so here too. > We'd like to not have to deploy the codebase multiple times either > (since it's identical) so we're trying to figure out a way maybe to > load each instance into mongrel with different params and then let > the instance configure itself. If your application is equal (or at least, only database and public/ configuration differ) you should check Fossilize plugin. Its too "crude", but John W. Long (Radiant CMS) implemented it in a better way to suit "instancing" based on gems or folders where you store the main code base and redirect to instances. > > Does anyone have experience using mongrel in this way or similar? Also, mongrel works good under this scenario. You should check the sample code and the docs about creating daemons for mongrel_cluster that load your specific root path. > > Thanks, > John > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From jeroen at supercool.nl Thu Sep 7 01:45:51 2006 From: jeroen at supercool.nl (Jeroen Houben) Date: Thu, 07 Sep 2006 07:45:51 +0200 Subject: [Mongrel] Running multiple domains on one codebase, mongrel a good choice? In-Reply-To: References: Message-ID: <44FFB20F.20507@supercool.nl> John Clayton wrote: > We're working on rails application for a client that needs to be > deployed under a variety of domain names and needs the ability to > load custom configurations for the database, parts of the docroot, > caching, etc. based on the site we're serving. We use mongrel to > host some other single domain apps and would like to do so here too. > We'd like to not have to deploy the codebase multiple times either > (since it's identical) so we're trying to figure out a way maybe to > load each instance into mongrel with different params and then let > the instance configure itself. > > Does anyone have experience using mongrel in this way or similar? I'm using different custum environments for different sites. Zed gave me that idea. I also have a mongrel_cluster.conf for each site that will load the correct environment. Then in my Apache vhost config I link the right site to the mongrel instances. I override a small method in rails to load assests from an site specific location instead of just public/ HTH, Jeroen From jaredbrown at gmail.com Thu Sep 7 02:38:50 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Thu, 7 Sep 2006 02:38:50 -0400 Subject: [Mongrel] Running two clusters side by side Message-ID: I'm happy to announce that ChaCha.com a new search engine that debuted this week and it runs on a mongrel cluster. Warning, promo follows. :) ChaCha.com is unlike any other search engine since it allows you to connect to a "guide" with experience in the field(s) of knowledge you are searching in. (Based on your keywords) Check it out at http://www.chacha.com Now on to my question. How can I run two clusters side by side so that when the site needs to be updated the new code can be deployed, then first one cluster is restarted and then the other, thus preventing any downtime from occuring? BTW: We are using mod_proxy_balancer to load balance between the mongrel servers. I imagine I would have to disable the proxy pass through at the same time, which would mean restarting apache several times. What is the best way to do this on one server? Thanks in advance. -- Jared Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/a8b01e27/attachment-0001.html From zedshaw at zedshaw.com Thu Sep 7 03:19:10 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 07 Sep 2006 00:19:10 -0700 Subject: [Mongrel] Running two clusters side by side In-Reply-To: References: Message-ID: <1157613550.8504.14.camel@localhost.localdomain> On Thu, 2006-09-07 at 02:38 -0400, Jared Brown wrote: > I'm happy to announce that ChaCha.com a new search engine that debuted > this week and it runs on a mongrel cluster. > > Warning, promo follows. :) > ChaCha.com is unlike any other search engine since it allows you to > connect to a "guide" with experience in the field(s) of knowledge you > are searching in. (Based on your keywords) Check it out at > http://www.chacha.com > Very cool. > Now on to my question. How can I run two clusters side by side so that > when the site needs to be updated the new code can be deployed, then > first one cluster is restarted and then the other, thus preventing any > downtime from occuring? BTW: We are using mod_proxy_balancer to load > balance between the mongrel servers. I imagine I would have to disable > the proxy pass through at the same time, which would mean restarting > apache several times. What is the best way to do this on one server? I believe most people do this with DNS tricks. Off the top of my head, what you do is you put your proxy out on the internet at chacha.com, and then point it at "prod1", "prod2", "prod3" on three other servers. These names come from an internal DNS. You then have three other servers named "staging1", "staging2", "staging3". You do your work against these three, and when the big day comes, you simply flop the records in your internal DNS so that staging becomes prod and v.v. The proxy server, using the internal DNS starts routing requests at the new IP addresses and old requests finish off as expected. There's also some fancy load balancers that can do the same thing from a control panel. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From krisleech at interkonect.com Thu Sep 7 04:20:54 2006 From: krisleech at interkonect.com (Kris Leech) Date: Thu, 07 Sep 2006 09:20:54 +0100 Subject: [Mongrel] Error on Windows and FreeBSD In-Reply-To: <71166b3b0609061236l737c68d1r4f1c79a7f3a37cc1@mail.gmail.com> References: <44FED057.9030001@alternativefocusmedia.com> <71166b3b0609061236l737c68d1r4f1c79a7f3a37cc1@mail.gmail.com> Message-ID: <44FFD666.2040903@interkonect.com> Luis Lavena wrote: >Wow, that's nasty. > >What version of mongrel gem are you using? > > The latest version only installed this week. >Also, you said on Windows, but which one? > > XP >What ruby distro are you using? (hope mswin32 of 1.8.4 which is based >on VC6, same for One-Click Installer). > > Latest version of 1.8.4, which is compiled with VC6++. >It is only thrown apart when calling that method? which code contains? >(please paste for better understanding of what are you doing that >brake so badly). > > I dont have the code to hand today, but its a very simple class, almost a bare ActiveRecord class. > >On 9/6/06, Kris Leech wrote: > > >>First off Windows, because actually what I appear to be getting is a >>Rails error which only occurs when I use Mongrel, using Webrick I do not >>get this error. >>I start Mongrel using: >>mongrel_rails start >> >>I have mongrel, win32-services and mongrel-service gems installed even >>through Im not using mongrel as a service at the moment. >> >>The whole application works apart from one action. The error I get is: >> >> >> NoMethodError in SearchController#results >> >>undefined method `table_name' for Stop:Class >> >>|(__DELEGATION__):2:in `__send__' >>(__DELEGATION__):2:in `table_name' >>#{RAILS_ROOT}/app/models/search.rb:58:in `find_runs' >>#{RAILS_ROOT}/app/models/search.rb:44:in `depature_runs' >>#{RAILS_ROOT}/app/controllers/search_controller.rb:100:in `results'| >> >> >> So my results action gives an error for table_name! The Stop model is >> used by various other controllers just fine. In Console I can do >> Stop.find_all, so I dont see how this error is being generated, >> besides the application server, mongrel, webrick or other, should not >> have any effect once it palms the request off to dispatcher? >> >> >>Many thanks AFM. >> >>PS. The freeBSD error can wait for another time :) >> >>_______________________________________________ >>Mongrel-users mailing list >>Mongrel-users at rubyforge.org >>http://rubyforge.org/mailman/listinfo/mongrel-users >> >> >> > > > > From zedshaw at zedshaw.com Thu Sep 7 04:21:57 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 07 Sep 2006 01:21:57 -0700 Subject: [Mongrel] [ANN] Mongrel Ultimate Deployment Certified Rails Aptitude Program Message-ID: <1157617317.8504.17.camel@localhost.localdomain> I'm proud to announce the official Mongrel certification program: http://mongrel.rubyforge.org/certified.html Move quick, seats are filling fast for the RubyConf courses. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From krisleech at interkonect.com Thu Sep 7 04:23:27 2006 From: krisleech at interkonect.com (Kris Leech) Date: Thu, 07 Sep 2006 09:23:27 +0100 Subject: [Mongrel] Error on Windows and FreeBSD In-Reply-To: <1157574259.8504.4.camel@localhost.localdomain> References: <44FED057.9030001@alternativefocusmedia.com> <1157574259.8504.4.camel@localhost.localdomain> Message-ID: <44FFD6FF.5080903@interkonect.com> Zed Shaw wrote: >On Wed, 2006-09-06 at 14:42 +0100, Kris Leech wrote: > > >>First off Windows, because actually what I appear to be getting is a >>Rails error which only occurs when I use Mongrel, using Webrick I do not >>get this error. >>I start Mongrel using: >>mongrel_rails start >> >>I have mongrel, win32-services and mongrel-service gems installed even >>through Im not using mongrel as a service at the moment. >> >>The whole application works apart from one action. The error I get is: >> >> >> NoMethodError in SearchController#results >> >>undefined method `table_name' for Stop:Class >> >> > >Mongrel already has created a class called "Stop", so your class is >conflicting with it. > >Basically, Stop, Start, Restart, are all classes in mongrel to make the >commands work. > > I see. Hence why it works with webrick and not mongrel. I think we need a page in the wiki about possible name clashes, is it all classes in mongrel that will clash or just specific ones? I feel a bit out of order saying this, but would Stop, Start etc. not be better as methods to a single class? > > > From al-mongrelusers at none.at Thu Sep 7 05:28:15 2006 From: al-mongrelusers at none.at (Alexander Lazic) Date: Thu, 7 Sep 2006 11:28:15 +0200 Subject: [Mongrel] Running two clusters side by side In-Reply-To: References: Message-ID: <20060907092815.GA18815@none.at> On Don 07.09.2006 02:38, Jared Brown wrote: > >Now on to my question. How can I run two clusters side by side so that >when the site needs to be updated the new code can be deployed, then >first one cluster is restarted and then the other, thus preventing any >downtime from occuring? BTW: We are using mod_proxy_balancer to load >balance between the mongrel servers. I imagine I would have to disable >the proxy pass through at the same time, which would mean restarting >apache several times. What is the best way to do this on one server? I use for this the haproxy with the following Setup: 1.) haproxy makes a cookie-session stickieness. 2.) haproxy check a /alive.data if the backend server is alive (option httpchk) 3.) haproxy have set the 'option persist and redispatch' flags Now if you want to make a update you only need to use the following steps: 1.) move the /alive.data to /alive.data.offline 2.) wait that all customers have been logout or after a $TIME 3.) make your maintenance 4.) move the /alive.data.offline to /alive.data 5.) and now it works as before with the *new* App ;-) More ideas/solution you can find here: http://haproxy.1wt.eu/download/1.2/doc/architecture.txt E.g.: 4. Soft-stop for application maintenance Hth && regards Alex From gethemant at gmail.com Thu Sep 7 06:44:40 2006 From: gethemant at gmail.com (hemant) Date: Thu, 7 Sep 2006 16:14:40 +0530 Subject: [Mongrel] what should be correct .conf file for being served by apache for static content Message-ID: Recently while i turned on USR1 debugging...mongrel running behind Apache2.2threw following debugging messages: Thu Sep 07 15:58:30 IST 2006: 0 threads sync_waiting for /charts/%5EBSESN, 1 still active in mongrel. Thu Sep 07 15:58:40 IST 2006: 0 threads sync_waiting for /images/tab_but_normal1.png, 3 still active in mongrel. Thu Sep 07 15:58:40 IST 2006: 0 threads sync_waiting for /images/msgBg1.gif, 3 still active in mongrel. Thu Sep 07 15:58:40 IST 2006: 0 threads sync_waiting for /images/flash/video/BloomBerg.jpg, 1 still active in mongrel. Now..Zed earlier...pointed that, why the hell..your mongrel is serving static content.Well, thankfully earlier logs were from mongrel running standalone in development mode. But how about the above? why I am still getting these logs? Are my static pages served by mongrel: > ServerAdmin webmaster at dummy-host.example.com > DocumentRoot /var/www/ubac_webfront/public > ServerName foobar.com > ServerAlias *.foobar.com > > Options FollowSymLinks > AllowOverride None > Order allow,deny > Allow from all > > RewriteEngine On > > # Make sure people go to www.myapp.com, not myapp.com > RewriteCond %{HTTP_HOST} ^foobar.com$ [NC] > RewriteRule ^(.*)$ http://www.foobar.com$1 [R=301,L] > # Yes, I've read no-www.com, but my site already has much Google-Fu on > # www.blah.com. Feel free to comment this out. > > # Uncomment for rewrite debugging > #RewriteLog logs/myapp_rewrite_log > #RewriteLogLevel 9 > > # Check for maintenance file and redirect all requests > RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f > RewriteCond %{SCRIPT_FILENAME} !maintenance.html > RewriteRule ^.*$ /system/maintenance.html [L] > > # Rewrite index to check for static > RewriteRule ^/$ /index.html [QSA] > > # Rewrite to check for Rails cached page > RewriteRule ^([^.]+)$ $1.html [QSA] > > # Redirect all non-static requests to cluster > RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f > RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] > > # Deflate > AddOutputFilterByType DEFLATE text/html text/plain text/xml > application/xml application/xhtml+xml text/javascript text/css > BrowserMatch ^Mozilla/4 gzip-only-text/html > BrowserMatch ^Mozilla/4.0[678] no-gzip > BrowserMatch bMSIE !no-gzip !gzip-only-text/html > # Uncomment for deflate debugging > #DeflateFilterNote Input input_info > #DeflateFilterNote Output output_info > #DeflateFilterNote Ratio ratio_info > #LogFormat '"%r" %{output_info}n/%{input_info}n (%{ratio_info}n%%)' > deflate > #CustomLog logs/myapp_deflate_log deflate > It is just a copy and paste of coda and philip's configurations. -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/fda8ec16/attachment.html From g.vishnu at gmail.com Thu Sep 7 06:57:41 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Thu, 7 Sep 2006 16:27:41 +0530 Subject: [Mongrel] [ANN] Mongrel Ultimate Deployment Certified Rails Aptitude Program In-Reply-To: <1157617317.8504.17.camel@localhost.localdomain> References: <1157617317.8504.17.camel@localhost.localdomain> Message-ID: :-) On 9/7/06, Zed Shaw wrote: > I'm proud to announce the official Mongrel certification program: > > http://mongrel.rubyforge.org/certified.html > > Move quick, seats are filling fast for the RubyConf courses. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From lapomme00 at gmail.com Thu Sep 7 08:37:22 2006 From: lapomme00 at gmail.com (Brett Walker) Date: Thu, 7 Sep 2006 20:37:22 +0800 Subject: [Mongrel] what should be correct .conf file for being served by apache for static content In-Reply-To: References: Message-ID: Hemant, I went through this same issue a couple of days ago. I had it configured just like you do, and thought Apache was serving the static files. Took me half a day to figure out the problem. My problem ended up being the permissions on the base directory. Was serving my app from a subdir in my home directory, and it didn't have the correct permission for the apache process to read it. I did a chmod 755 /home/myuser and suddenly Apache could server the static files. Also, if you stop Mongrel, then try to serve one of your static files, you can tell for sure whether Apache is serving it or not. Cheers, Brett On 9/7/06, hemant wrote: > Recently while i turned on USR1 debugging...mongrel running behind Apache2.2 > threw following debugging messages: > > Thu Sep 07 15:58:30 IST 2006: 0 threads sync_waiting for /charts/%5EBSESN, 1 > still active in mongrel. > Thu Sep 07 15:58:40 IST 2006: 0 threads sync_waiting for > /images/tab_but_normal1.png, 3 still active in mongrel. > Thu Sep 07 15:58:40 IST 2006: 0 threads sync_waiting for /images/msgBg1.gif, > 3 still active in mongrel. > Thu Sep 07 15:58:40 IST 2006: 0 threads sync_waiting for > /images/flash/video/BloomBerg.jpg, 1 still active in > mongrel. > > > Now..Zed earlier...pointed that, why the hell..your mongrel is serving > static content.Well , thankfully earlier logs were from mongrel running > standalone in development mode. > But how about the above? why I am still getting these logs? Are my static > pages served by mongrel: > > > > > > ServerAdmin webmaster at dummy-host.example.com > > DocumentRoot /var/www/ubac_webfront/public > > ServerName foobar.com > > ServerAlias *.foobar.com > > > > Options FollowSymLinks > > AllowOverride None > > Order allow,deny > > Allow from all > > > > RewriteEngine On > > > > # Make sure people go to www.myapp.com, not myapp.com > > RewriteCond %{HTTP_HOST} ^foobar.com$ [NC] > > RewriteRule ^(.*)$ http://www.foobar.com$1 [R=301,L] > > # Yes, I've read no-www.com, but my site already has much Google-Fu on > > # www.blah.com. Feel free to comment this out. > > > > # Uncomment for rewrite debugging > > #RewriteLog logs/myapp_rewrite_log > > #RewriteLogLevel 9 > > > > # Check for maintenance file and redirect all requests > > RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f > > RewriteCond %{SCRIPT_FILENAME} !maintenance.html > > RewriteRule ^.*$ /system/maintenance.html [L] > > > > # Rewrite index to check for static > > RewriteRule ^/$ /index.html [QSA] > > > > # Rewrite to check for Rails cached page > > RewriteRule ^([^.]+)$ $1.html [QSA] > > > > # Redirect all non-static requests to cluster > > RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f > > RewriteRule ^/(.*)$ > balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] > > > > # Deflate > > AddOutputFilterByType DEFLATE text/html text/plain text/xml > application/xml application/xhtml+xml text/javascript text/css > > BrowserMatch ^Mozilla/4 gzip-only-text/html > > BrowserMatch ^Mozilla/4.0[678] no-gzip > > BrowserMatch bMSIE !no-gzip !gzip-only-text/html > > # Uncomment for deflate debugging > > #DeflateFilterNote Input input_info > > #DeflateFilterNote Output output_info > > #DeflateFilterNote Ratio ratio_info > > #LogFormat '"%r" %{output_info}n/%{input_info}n (%{ratio_info}n%%)' > deflate > > #CustomLog logs/myapp_deflate_log deflate > > > > It is just a copy and paste of coda and philip's configurations. > > -- > nothing much to talk > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From tperrett at butlerandtanner.com Thu Sep 7 08:57:28 2006 From: tperrett at butlerandtanner.com (Tim Perrett) Date: Thu, 07 Sep 2006 13:57:28 +0100 Subject: [Mongrel] [ANN] Mongrel Ultimate Deployment Certified Rails Aptitude Program Message-ID: HAHAHAHA, top quality, thanks for that zed, that article just added a smile to an otherwise dreary day!!! Tim Perrett ------------------------------ Date: Thu, 07 Sep 2006 01:21:57 -0700 From: Zed Shaw Subject: [Mongrel] [ANN] Mongrel Ultimate Deployment Certified Rails Aptitude Program To: "mongrel-users at rubyforge.org" Message-ID: <1157617317.8504.17.camel at localhost.localdomain> Content-Type: text/plain I'm proud to announce the official Mongrel certification program: http://mongrel.rubyforge.org/certified.html Move quick, seats are filling fast for the RubyConf courses. -- Zed A. Shaw ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ From zedshaw at zedshaw.com Thu Sep 7 09:00:08 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 07 Sep 2006 06:00:08 -0700 Subject: [Mongrel] what should be correct .conf file for being served by apache for static content In-Reply-To: References: Message-ID: <1157634008.27180.2.camel@localhost.localdomain> On Thu, 2006-09-07 at 20:37 +0800, Brett Walker wrote: > Hemant, > > I went through this same issue a couple of days ago. I had it > configured just like you do, and thought Apache was serving the static > files. Took me half a day to figure out the problem. > > My problem ended up being the permissions on the base directory. Was > serving my app from a subdir in my home directory, and it didn't have > the correct permission for the apache process to read it. I did a > > chmod 755 /home/myuser > > and suddenly Apache could server the static files. > > Also, if you stop Mongrel, then try to serve one of your static files, > you can tell for sure whether Apache is serving it or not. Hmmm, I might add that to the FAQ. Weird that apache wouldn't consider that an error. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From lapomme00 at gmail.com Thu Sep 7 09:21:36 2006 From: lapomme00 at gmail.com (Brett Walker) Date: Thu, 7 Sep 2006 21:21:36 +0800 Subject: [Mongrel] what should be correct .conf file for being served by apache for static content In-Reply-To: <1157634008.27180.2.camel@localhost.localdomain> References: <1157634008.27180.2.camel@localhost.localdomain> Message-ID: Well, I was getting a '(13)Permission denied: ', but the permissions on my rails directory were fine. It was one of the parent directories that were wrong, and it took me awhile to figure that out. Maybe I'm just too much of a newbie. On 9/7/06, Zed Shaw wrote: > On Thu, 2006-09-07 at 20:37 +0800, Brett Walker wrote: > > Hemant, > > > > I went through this same issue a couple of days ago. I had it > > configured just like you do, and thought Apache was serving the static > > files. Took me half a day to figure out the problem. > > > > My problem ended up being the permissions on the base directory. Was > > serving my app from a subdir in my home directory, and it didn't have > > the correct permission for the apache process to read it. I did a > > > > chmod 755 /home/myuser > > > > and suddenly Apache could server the static files. > > > > Also, if you stop Mongrel, then try to serve one of your static files, > > you can tell for sure whether Apache is serving it or not. > > Hmmm, I might add that to the FAQ. Weird that apache wouldn't consider > that an error. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From thejohnny at gmail.com Thu Sep 7 11:16:30 2006 From: thejohnny at gmail.com (John Carlin) Date: Thu, 7 Sep 2006 10:16:30 -0500 Subject: [Mongrel] [ANN] Mongrel Ultimate Deployment Certified Rails Aptitude Program In-Reply-To: References: Message-ID: I'm sure there was no pun intended for "seats are filling fast". On 9/7/06, Tim Perrett wrote: > HAHAHAHA, top quality, thanks for that zed, that article just added a smile > to an otherwise dreary day!!! > > Tim Perrett > > ------------------------------ > Date: Thu, 07 Sep 2006 01:21:57 -0700 > From: Zed Shaw > Subject: [Mongrel] [ANN] Mongrel Ultimate Deployment Certified Rails > Aptitude Program > To: "mongrel-users at rubyforge.org" > Message-ID: <1157617317.8504.17.camel at localhost.localdomain> > Content-Type: text/plain > > > I'm proud to announce the official Mongrel certification program: > > http://mongrel.rubyforge.org/certified.html > > Move quick, seats are filling fast for the RubyConf courses. > > -- > Zed A. Shaw > > > > > ________________________________________________________________________ > This e-mail has been scanned for all viruses by Star. The > service is powered by MessageLabs. For more information on a proactive > anti-virus service working around the clock, around the globe, visit: > http://www.star.net.uk > ________________________________________________________________________ > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From jamesludlow at gmail.com Thu Sep 7 11:27:35 2006 From: jamesludlow at gmail.com (James Ludlow) Date: Thu, 7 Sep 2006 10:27:35 -0500 Subject: [Mongrel] [ANN] Mongrel Ultimate Deployment Certified Rails Aptitude Program In-Reply-To: <1157617317.8504.17.camel@localhost.localdomain> References: <1157617317.8504.17.camel@localhost.localdomain> Message-ID: On 9/7/06, Zed Shaw wrote: > I'm proud to announce the official Mongrel certification program: > > http://mongrel.rubyforge.org/certified.html > > Move quick, seats are filling fast for the RubyConf courses. All I need is my MUDCRAP-CE and a large spinning mirror, and I could vaporize a human target from space. Sign me up please. From wyhaines at gmail.com Thu Sep 7 13:23:01 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Thu, 7 Sep 2006 11:23:01 -0600 Subject: [Mongrel] Recommended testing approaches for new Mongrel handlers? In-Reply-To: <1153341382.6707.3.camel@localhost.localdomain> References: <1153341382.6707.3.camel@localhost.localdomain> Message-ID: On 7/19/06, Zed Shaw wrote: > > Is there any set of standard sorts of things that have been devised to > > test the other handlers that I could apply to my new handlers? > > Kirk! You're awake! Awesome, since I'm actually writing the "Mongrel > HTTP Compliance Test Suite" using RFuzz right now. If you want I can > get with you when I have a bit to run and we can work IOWA into the > suite. > > The approach of the suite is that it will start up a target web app with > a test web application in it. Then the test suite hits it to verify it > meets compliance with the RFC. It does this with different mongrel > configs and would run for each web framework. The goal is to make it so > that framework authors can validate that their framework is "Mongrel > Compliant". Zed, what is the state of this? I'd love to expand on my rudimentary tests for the IOWA+Mongrel integration and see if there's anything that I broke that shouldn't be broken. Thanks, Kirk Haines From john at fivesquaresoftware.com Thu Sep 7 14:40:50 2006 From: john at fivesquaresoftware.com (John Clayton) Date: Thu, 7 Sep 2006 11:40:50 -0700 Subject: [Mongrel] Mass virtual hosting with mongrel Message-ID: Ok, a refinement of the question I asked yesterday (If there were any replies from yesterday I don't have access to them here .. sorry if I'm duplicating anybody's words here). How can one host multiple domains with mongrel? Assuming you are mass vhosting and you also want the performance benefits of using mongrel ... As far as I can tell, one could set up a vhost in Apache and a mongrel (cluster) for each host and have that be that. But let's say you can have an unlimited number of vhosts, this will get seriously tedious and error prone. A great thing about Apache is the ability to interpolate docroots, so you can add infinite vhosts super easy. But, for this to work with Mongrel, it would have to have the same ability, be able to take a request and feed it to the correct app based on some parameters of the request. I haven't yet looked at Mongrel's internals, but for those of you with experience there, would it be difficult or is it even a good idea to create a parallel to mongrel_rails, something like mongrel_rails_vhosts or the like? My understanding of plugins is that they can only extend mongrel_rails by adding commands, true? I imagine it would be similar to mongrel_rails but with a dispatcher layer that can be multithreaded and send requests to the correct app based on the request. Or would something like mongrel_cluster, but with the added dispatching layer there be a better approach? Love to hear anyone's thoughts ... if it seems promising, I'll take it on. Cheers, John From jason at joyent.com Thu Sep 7 14:50:08 2006 From: jason at joyent.com (Jason A. Hoffman) Date: Thu, 7 Sep 2006 11:50:08 -0700 Subject: [Mongrel] Mass virtual hosting with mongrel In-Reply-To: References: Message-ID: <79F0BB25-32DA-40E4-AFC7-E3F1F6C4417F@joyent.com> What are you mass virtual hosting exactly? And what I mean by this is that with one of our apps (the connector), I can have either connector.jasonhoffman.org or jason.joyent.net pull up my webmail, contacts, calendaring, files etc and that's distinct from anyoneelse.joyent.net and they can have as many other domains map to it as they want. We do this all via stateless (in this context) mongrel processes, anyone can hit any of them and get their stuff. Or are you talking about the mass virtual hosting of many different Rails or Ruby applications? - J On Sep 7, 2006, at 11:40 AM, John Clayton wrote: > Ok, a refinement of the question I asked yesterday (If there were any > replies from yesterday I don't have access to them here .. sorry if > I'm duplicating anybody's words here). > > How can one host multiple domains with mongrel? Assuming you are mass > vhosting and you also want the performance benefits of using > mongrel ... > > As far as I can tell, one could set up a vhost in Apache and a > mongrel (cluster) for each host and have that be that. But let's say > you can have an unlimited number of vhosts, this will get seriously > tedious and error prone. > > A great thing about Apache is the ability to interpolate docroots, so > you can add infinite vhosts super easy. But, for this to work with > Mongrel, it would have to have the same ability, be able to take a > request and feed it to the correct app based on some parameters of > the request. > > I haven't yet looked at Mongrel's internals, but for those of you > with experience there, would it be difficult or is it even a good > idea to create a parallel to mongrel_rails, something like > mongrel_rails_vhosts or the like? My understanding of plugins is that > they can only extend mongrel_rails by adding commands, true? I > imagine it would be similar to mongrel_rails but with a dispatcher > layer that can be multithreaded and send requests to the correct app > based on the request. Or would something like mongrel_cluster, but > with the added dispatching layer there be a better approach? > > Love to hear anyone's thoughts ... if it seems promising, I'll take > it on. > > Cheers, > > John > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From wyhaines at gmail.com Thu Sep 7 14:51:38 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Thu, 7 Sep 2006 12:51:38 -0600 Subject: [Mongrel] Mass virtual hosting with mongrel In-Reply-To: References: Message-ID: On 9/7/06, John Clayton wrote: > How can one host multiple domains with mongrel? Assuming you are mass > vhosting and you also want the performance benefits of using mongrel ... If I remember right, you are looking at a situtation where you have a single application that will have a different look and feel applied, depending on the domain it is being served to, right? So couldn't you just set up your app to look at the SERVER_NAME and choose the theme for the content appropriately? Then you just setup your Apache vhosts and feel all the traffic into the same mongrel cluster, and you don't have to do anything at all at the Mongrel level, right? You leave it to your app to be multidomain aware? What am I missing? Kirk Haines From me at seebq.com Thu Sep 7 15:43:36 2006 From: me at seebq.com (Charles Brian Quinn) Date: Thu, 7 Sep 2006 15:43:36 -0400 Subject: [Mongrel] Mass virtual hosting with mongrel In-Reply-To: References: Message-ID: <3a2de0cd0609071243i7f95892fw3ffee75f62c4d9bc@mail.gmail.com> And if this is the case, we just wrote something up on using this kind of "subdomain" auth as part of a key -- all one app, serving up different "content" / "dashboards" / "features": http://cleanair.highgroove.com/articles/2006/08/14/simplied-subdomain-authentication-in-ruby-on-rails The key is a DNS wildcard record: *.yourdomain.com forwarded to the main web/app server and rules for handling what it does. I hope we didn't mangle your question too badly, On 9/7/06, Kirk Haines wrote: > On 9/7/06, John Clayton wrote: > > > How can one host multiple domains with mongrel? Assuming you are mass > > vhosting and you also want the performance benefits of using mongrel ... > > If I remember right, you are looking at a situtation where you have a > single application that will have a different look and feel applied, > depending on the domain it is being served to, right? > > So couldn't you just set up your app to look at the SERVER_NAME and > choose the theme for the content appropriately? > > Then you just setup your Apache vhosts and feel all the traffic into > the same mongrel cluster, and you don't have to do anything at all at > the Mongrel level, right? You leave it to your app to be multidomain > aware? > > What am I missing? > > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com From john at fivesquaresoftware.com Thu Sep 7 15:46:08 2006 From: john at fivesquaresoftware.com (John Clayton) Date: Thu, 7 Sep 2006 12:46:08 -0700 Subject: [Mongrel] Mass virtual hosting with mongrel In-Reply-To: References: Message-ID: <011DAF24-CC23-4425-9104-4C8198AACD8E@fivesquaresoftware.com> Hey Guys, Thanks for the quick replies. Some more info: As you mention, Kirk, we are looking to host different instances of the same app, correct. Basically, let's say we are hosting an online community app, with one instance each for a particular region in a geographical area. So, we'd like a different instance, as opposed to a single instance that switches the underlying context?DB connection, config info, etc.?so that we can keep the data partitioned nicely, not adversely affect performance (these could get a lot of traffic and we'd like to have each one partitioned from the others in case one has issues), have a unique docroot for file storage, etc.. Also, these apps have to be dynamically provisioned?that is, not require a Web server restart or any human intervention to create a new instance. To wit, our plan is to deploy app stubs that link in the shared codebase (haven't figured that one out), and use Apache's docroot interpolation to look up an instantiate the correct instance. We use mongrel for other apps now and really like it?it's made our apps a lot snappier and the reverse proxying stuff just works. The problem (as I see it, and maybe I'm wrong) amounts to being able to not have to create and configure a new mongrel (or cluster) every time we dynamically provision an app. This would involve modifying our Apache conf, restarting, keeping track of used ports, etc., and this we sincerely want to avoid. So, this is when I started to think that it might be possible to add to mongrel functionality similar to what apache does or say what you might do with a J2EE container?host multiple apps in one container and add some sort of dispatching to route requests to the right place. Thanks for your insight. Jason, I'm not sure I totally understand what you're doing with your connectors, but I'd like to hear more ... On Sep 7, 2006, at 11:50 AM, Jason A. Hoffman wrote: > What are you mass virtual hosting exactly? > > And what I mean by this is that with one of our apps (the connector), > I can have either connector.jasonhoffman.org or jason.joyent.net pull > up my webmail, contacts, calendaring, files etc and that's distinct > from anyoneelse.joyent.net and they can have as many other domains > map to it as they want. > > We do this all via stateless (in this context) mongrel processes, > anyone can hit any of them and get their stuff. > > Or are you talking about the mass virtual hosting of many different > Rails or Ruby applications? > > - J On Sep 7, 2006, at 11:51 AM, Kirk Haines wrote: > On 9/7/06, John Clayton wrote: > >> How can one host multiple domains with mongrel? Assuming you are mass >> vhosting and you also want the performance benefits of using >> mongrel ... > > If I remember right, you are looking at a situtation where you have a > single application that will have a different look and feel applied, > depending on the domain it is being served to, right? > > So couldn't you just set up your app to look at the SERVER_NAME and > choose the theme for the content appropriately? > > Then you just setup your Apache vhosts and feel all the traffic into > the same mongrel cluster, and you don't have to do anything at all at > the Mongrel level, right? You leave it to your app to be multidomain > aware? > > What am I missing? > > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From gethemant at gmail.com Thu Sep 7 16:15:37 2006 From: gethemant at gmail.com (hemant) Date: Fri, 8 Sep 2006 01:45:37 +0530 Subject: [Mongrel] Error on Windows and FreeBSD In-Reply-To: <44FFD6FF.5080903@interkonect.com> References: <44FED057.9030001@alternativefocusmedia.com> <1157574259.8504.4.camel@localhost.localdomain> <44FFD6FF.5080903@interkonect.com> Message-ID: I can add some of my own....name collisions here: you shouldn't have a table called messages and you shouldn't have a column called quote. On 9/7/06, Kris Leech wrote: > > Zed Shaw wrote: > > >On Wed, 2006-09-06 at 14:42 +0100, Kris Leech wrote: > > > > > >>First off Windows, because actually what I appear to be getting is a > >>Rails error which only occurs when I use Mongrel, using Webrick I do not > >>get this error. > >>I start Mongrel using: > >>mongrel_rails start > >> > >>I have mongrel, win32-services and mongrel-service gems installed even > >>through Im not using mongrel as a service at the moment. > >> > >>The whole application works apart from one action. The error I get is: > >> > >> > >> NoMethodError in SearchController#results > >> > >>undefined method `table_name' for Stop:Class > >> > >> > > > >Mongrel already has created a class called "Stop", so your class is > >conflicting with it. > > > >Basically, Stop, Start, Restart, are all classes in mongrel to make the > >commands work. > > > > > I see. Hence why it works with webrick and not mongrel. I think we need > a page in the wiki about possible name clashes, is it all classes in > mongrel that will clash or just specific ones? > I feel a bit out of order saying this, but would Stop, Start etc. not be > better as methods to a single class? > > > > > > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/76b53936/attachment.html From joeat303 at yahoo.com Thu Sep 7 16:35:12 2006 From: joeat303 at yahoo.com (Joe Ruby) Date: Thu, 7 Sep 2006 13:35:12 -0700 (PDT) Subject: [Mongrel] LiteSpeed Message-ID: <20060907203512.77792.qmail@web38610.mail.mud.yahoo.com> Yo Zed, Just curious -- what do you think of the LiteSpeed server? Is it better than Lighty? Does it (gasp!) also serve Rails apps like Mongrel? I think I read that LiteSpeed doesn't have proxying support. Thanks, Joe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From joeat303 at yahoo.com Thu Sep 7 16:38:56 2006 From: joeat303 at yahoo.com (Joe Ruby) Date: Thu, 7 Sep 2006 13:38:56 -0700 (PDT) Subject: [Mongrel] [ANN] Mongrel Ultimate Deployment Certified Rails Aptitude Program Message-ID: <20060907203856.79100.qmail@web38604.mail.mud.yahoo.com> On 9/7/06, Zed Shaw wrote: > I'm proud to announce the official Mongrel certification program: > > http://mongrel.rubyforge.org/certified.html Heh, that's some funny CRAP! ;) Joe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From technoweenie at gmail.com Thu Sep 7 16:45:16 2006 From: technoweenie at gmail.com (Rick Olson) Date: Thu, 7 Sep 2006 15:45:16 -0500 Subject: [Mongrel] LiteSpeed In-Reply-To: <20060907203512.77792.qmail@web38610.mail.mud.yahoo.com> References: <20060907203512.77792.qmail@web38610.mail.mud.yahoo.com> Message-ID: <48fe25b0609071345l680e759fh743b9d65e22784de@mail.gmail.com> On 9/7/06, Joe Ruby wrote: > Yo Zed, > > Just curious -- what do you think of the LiteSpeed > server? Is it better than Lighty? Does it (gasp!) also > serve Rails apps like Mongrel? I think I read that > LiteSpeed doesn't have proxying support. > > Thanks, > Joe It does have proxying support, but it doesn't have any mod_rewrite capabilities before proxying last I checked. This makes it a lousy frontend for Mongrel. But all the claims of speed and ease-of-setup are with Litespeed's proprietary LSAPI, and not mongrel. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com From mike at harmonypark.net Thu Sep 7 17:01:57 2006 From: mike at harmonypark.net (Mike Evans) Date: Thu, 7 Sep 2006 22:01:57 +0100 Subject: [Mongrel] Upload progress and limiting file sizes Message-ID: <643C1991-7EC2-4E17-B0E0-130B2320A2E8@harmonypark.net> Thanks to all concerned with the implementation of the Upload Progress plugin, it works really well. I want to limit the size of files to be uploaded to say 10Mb. Is there any way for Mongrel to 'refuse' to upload files over a certain size and then pass an error onto Rails in order to display feedback to the user? I don't really want to have to upload the whole file and then delete it if it's over the limit. What about the possibility of a user cancelling an upload that's currently in progress? Apologies if these questions are naive, but I've always taken web servers for granted so am very much a newb. Cheers, Mike From zerohalo at gmail.com Thu Sep 7 17:06:05 2006 From: zerohalo at gmail.com (zer0halo) Date: Thu, 7 Sep 2006 16:06:05 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel Message-ID: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> I'm trying to set up several different Rails apps on the same domain, each one running Mongrel. After reading all of the documentation, it's fairly clear how to use subdomains - create several Apache virtual hosts, each of which has a different ProxyPass and ProxyPassReverse command to redirect from different ports (ie, 3000, 3100), and then have each Mongrel instance (or cluster) set to the corresponding port (3000, 3100). [If this theory is incorrect, please let me know!] However, what I'm trying to acheive is to host them all under the same domain. In othe words, I would like to have www.domain.com/app1 www.domain.com/app2 I don't know how to acheive this. Do I make each of them Virtual Hosts, each with their own ProxyPass? (But I haven't been able to find any simple documentation online explaining how to set a Virtual Host at www.domain.com/app1 instead of app1.domain.com. I know fairly little about Apache.) I noticed in the Mongrel documentation mention of a --prefix command and I was wondering if that could be used to host multiple apps, but for one it's not clear how that ties in with Apache, and secondly, the latest version of mongrel_rails doesn't recognize that command. Any possibilities? Thank you. -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/06d59f5e/attachment.html From _ at whats-your.name Thu Sep 7 17:12:46 2006 From: _ at whats-your.name (carmen) Date: Thu, 7 Sep 2006 21:12:46 +0000 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> Message-ID: <20060907211246.GC26183@replic.net> On Thu Sep 07, 2006 at 04:06:05PM -0500, zer0halo wrote: > I'm trying to set up several different Rails apps on the same domain, each > one running Mongrel. After reading all of the documentation, it's fairly > clear how to use subdomains - create several Apache virtual hosts, each of > which has a different ProxyPass and ProxyPassReverse command to redirect > from different ports (ie, 3000, 3100), and then have each Mongrel instance > (or cluster) set to the corresponding port (3000, 3100). [If this theory is > incorrect, please let me know!] > > However, what I'm trying to acheive is to host them all under the same > domain. In othe words, I would like to have > > www.domain.com/app1 > www.domain.com/app2 maybe you can hack the mongrel_rails script to setup a rails handler for each app? camping does it this way anyways From john at fivesquaresoftware.com Thu Sep 7 17:21:03 2006 From: john at fivesquaresoftware.com (John Clayton) Date: Thu, 7 Sep 2006 14:21:03 -0700 Subject: [Mongrel] Mass virtual hosting with mongrel In-Reply-To: <3a2de0cd0609071243i7f95892fw3ffee75f62c4d9bc@mail.gmail.com> References: <3a2de0cd0609071243i7f95892fw3ffee75f62c4d9bc@mail.gmail.com> Message-ID: <26CEB085-017A-4C1A-B987-F3C3B6C7098B@fivesquaresoftware.com> Thanks, Charles. That's how we were planning on handling the DNS. What I don't think your approach doesn't address for us is partioning the app (db, config, roots, resources) to isolate the impact on performance and data migration. True? J On Sep 7, 2006, at 12:43 PM, Charles Brian Quinn wrote: > And if this is the case, we just wrote something up on using this kind > of "subdomain" auth as part of a key -- all one app, serving up > different "content" / "dashboards" / "features": > > http://cleanair.highgroove.com/articles/2006/08/14/simplied- > subdomain-authentication-in-ruby-on-rails > > The key is a DNS wildcard record: *.yourdomain.com forwarded to the > main web/app server and rules for handling what it does. > > I hope we didn't mangle your question too badly, > > On 9/7/06, Kirk Haines wrote: >> On 9/7/06, John Clayton wrote: >> >>> How can one host multiple domains with mongrel? Assuming you are >>> mass >>> vhosting and you also want the performance benefits of using >>> mongrel ... >> >> If I remember right, you are looking at a situtation where you have a >> single application that will have a different look and feel applied, >> depending on the domain it is being served to, right? >> >> So couldn't you just set up your app to look at the SERVER_NAME and >> choose the theme for the content appropriately? >> >> Then you just setup your Apache vhosts and feel all the traffic into >> the same mongrel cluster, and you don't have to do anything at all at >> the Mongrel level, right? You leave it to your app to be multidomain >> aware? >> >> What am I missing? >> >> >> Kirk Haines >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > > > -- > Charles Brian Quinn > self-promotion: www.seebq.com > highgroove studios: www.highgroove.com > slingshot hosting: www.slingshothosting.com > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From zerohalo at gmail.com Thu Sep 7 17:21:26 2006 From: zerohalo at gmail.com (zer0halo) Date: Thu, 7 Sep 2006 16:21:26 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <20060907211246.GC26183@replic.net> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> Message-ID: <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> if I was smart and knowledgeable enough I'm sure I could :-) but I was hoping for a bit of a simpler solution. Running multiple Rails apps on the same domain is something that in general seems quite tough to do. I think this is an issue that needs resolving by the rails-gods at some point as it could be hindrance to rails growth. Otherwise it's easy to draw comparisons with PHP where you just stick your apps in different folders under your Document Root (or use symlinks) and voila. Don't get be wrong, I'm definitely a Rails fan, and this isn't meant as a Rails vs PHP, but just pointing out something that is quite tricky in Rails - a framework which thrives on simplicity. It seems it should be as (relatively) straightforward as the rest of Rails is. Especially because Rails lends itself to creating little apps that each do their own thing well, but then at some point you want to combine them or mix and match, etc. On 9/7/06, carmen <_ at whats-your.name> wrote: > > On Thu Sep 07, 2006 at 04:06:05PM -0500, zer0halo wrote: > > I'm trying to set up several different Rails apps on the same domain, > each > > one running Mongrel. After reading all of the documentation, it's fairly > > clear how to use subdomains - create several Apache virtual hosts, each > of > > which has a different ProxyPass and ProxyPassReverse command to redirect > > from different ports (ie, 3000, 3100), and then have each Mongrel > instance > > (or cluster) set to the corresponding port (3000, 3100). [If this theory > is > > incorrect, please let me know!] > > > > However, what I'm trying to acheive is to host them all under the same > > domain. In othe words, I would like to have > > > > www.domain.com/app1 > > www.domain.com/app2 > > maybe you can hack the mongrel_rails script to setup a rails handler for > each app? camping does it this way anyways > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/8319bff4/attachment.html From technoweenie at gmail.com Thu Sep 7 17:26:34 2006 From: technoweenie at gmail.com (Rick Olson) Date: Thu, 7 Sep 2006 16:26:34 -0500 Subject: [Mongrel] Upload progress and limiting file sizes In-Reply-To: <643C1991-7EC2-4E17-B0E0-130B2320A2E8@harmonypark.net> References: <643C1991-7EC2-4E17-B0E0-130B2320A2E8@harmonypark.net> Message-ID: <48fe25b0609071426w2b954274q15699bcae144e698@mail.gmail.com> On 9/7/06, Mike Evans wrote: > Thanks to all concerned with the implementation of the Upload > Progress plugin, it works really well. > > I want to limit the size of files to be uploaded to say 10Mb. Is > there any way for Mongrel to 'refuse' to upload files over a certain > size and then pass an error onto Rails in order to display feedback > to the user? I don't really want to have to upload the whole file and > then delete it if it's over the limit. I don't know if this really belongs in upload progress, but it'd be a trivial handler to write. Might be better as a separate thing so that you could lock down every request with a limit, or use on sites w/o using upload_progress. > What about the possibility of a user cancelling an upload that's > currently in progress? Cancelling the current browser request works. Try calling .stop() on the iframe object. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com From bryan at galisys.com Thu Sep 7 17:35:24 2006 From: bryan at galisys.com (Bryan Thompson) Date: Thu, 7 Sep 2006 16:35:24 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> Message-ID: <99E916AA-291C-439C-8B65-337BF70ADD4E@galisys.com> I think this is basically how we're doing it. BalancerMember http://127.0.0.1:6000 BalancerMember http://127.0.0.1:6001 BalancerMember http://127.0.0.1:6002 BalancerMember http://127.0.0.1:6003 BalancerMember http://127.0.0.1:6004 BalancerMember http://127.0.0.1:7000 BalancerMember http://127.0.0.1:7001 BalancerMember http://127.0.0.1:7002 BalancerMember http://127.0.0.1:7003 BalancerMember http://127.0.0.1:7004 ProxyPass /app1/images ! ProxyPass /app1/stylesheets ! #continue with other static files that should be served by apache ProxyPass /app2/images ! ProxyPass /app2/stylesheets ! #continue with other static files that should be served by apache Alias /app1/images /path/to/public/images Alias /app1/stylesheets /path/to/public/stylesheets #continue with aliases for static content Alias /app2/images /path/to/public/images Alias /app2/stylesheets /path/to/public/stylesheets #continue with aliases for static content ProxyPass /app1 balancer://app1balancer ProxyPass /app2 balancer://app1balancer Bryan On Sep 7, 2006, at 4:06 PM, zer0halo wrote: > I'm trying to set up several different Rails apps on the same > domain, each one running Mongrel. After reading all of the > documentation, it's fairly clear how to use subdomains - create > several Apache virtual hosts, each of which has a different > ProxyPass and ProxyPassReverse command to redirect from different > ports (ie, 3000, 3100), and then have each Mongrel instance (or > cluster) set to the corresponding port (3000, 3100). [If this > theory is incorrect, please let me know!] > > However, what I'm trying to acheive is to host them all under the > same domain. In othe words, I would like to have > > www.domain.com/app1 > www.domain.com/app2 > > I don't know how to acheive this. Do I make each of them Virtual > Hosts, each with their own ProxyPass? (But I haven't been able to > find any simple documentation online explaining how to set a > Virtual Host at www.domain.com/app1 instead of app1.domain.com. I > know fairly little about Apache.) > > I noticed in the Mongrel documentation mention of a --prefix > command and I was wondering if that could be used to host multiple > apps, but for one it's not clear how that ties in with Apache, and > secondly, the latest version of mongrel_rails doesn't recognize > that command. > > Any possibilities? Thank you. > > -- > "Impossible is nothing." > _______________________________________________ > 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/20060907/e0dbab61/attachment.html From _ at whats-your.name Thu Sep 7 17:42:15 2006 From: _ at whats-your.name (carmen) Date: Thu, 7 Sep 2006 21:42:15 +0000 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> Message-ID: <20060907214215.GD26183@replic.net> On Thu Sep 07, 2006 at 04:21:26PM -0500, zer0halo wrote: > if I was smart and knowledgeable enough I'm sure I could :-) > but I was hoping for a bit of a simpler solution. > > Running multiple Rails apps on the same domain is something that in general > seems quite tough to do. its not so much tough, as varying extensively with the terrain (eg, apache, lighttpd, mongrel). im sure therse something on google that can explain how to point subdirs to different local ports, via apache's mod_proxy. proably even in the rails list archives. at most youll have to set an abstract_uri_root or something inenvironment.rb, on the rails side.. > I think this is an issue that needs resolving by > the rails-gods at some point as it could be hindrance to rails growth. > Otherwise it's easy to draw comparisons with PHP where you just stick your > apps in different folders under your Document Root (or use symlinks) and > voila. that is how it works with camping > Don't get be wrong, I'm definitely a Rails fan, and this isn't meant > as a Rails vs PHP, but just pointing out something that is quite tricky in > Rails - a framework which thrives on simplicity. thrives on presenting simplicity to the developer, you mean. thats part of it, but another angle is marketing. django and nitro arent as complex when it comes to 'what do i define in my schema and what do i define in code' as rails, but somehow they have had exponentially less hype, from my vantage point.. From jaredbrown at gmail.com Thu Sep 7 17:52:25 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Thu, 7 Sep 2006 17:52:25 -0400 Subject: [Mongrel] How to setup a sweeper to restart stale or hung mongrel servers Message-ID: How do I setup a sweeper to restart stale or hung mongrel servers? -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/0994017f/attachment.html From zerohalo at gmail.com Thu Sep 7 18:08:22 2006 From: zerohalo at gmail.com (zer0halo) Date: Thu, 7 Sep 2006 17:08:22 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <99E916AA-291C-439C-8B65-337BF70ADD4E@galisys.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <99E916AA-291C-439C-8B65-337BF70ADD4E@galisys.com> Message-ID: <92b38bd50609071508l30e6ec77y9b4bdff27fd840e3@mail.gmail.com> Thanks, Bryan, I tried it and am partway there, but it's still not working. http://domain/app1/controller/method does run the method and display the view, but the images and stylesheets are not loading (whether or not I have a ProxyPass for the images and stylesheets as you have below - I tried both with and without.) Also all links to other methods fail because .... http://domain/app1/controller redirects me to: http://domain/controller Which gives be an Apache 'page not found' error. I presume that would be something to fix in routes.rb, but I tried a couple of things and they didn't work. Thanks for any help. On 9/7/06, Bryan Thompson wrote: > > I think this is basically how we're doing it. > > > BalancerMember http://127.0.0.1:6000 > BalancerMember http://127.0.0.1:6001 > BalancerMember http://127.0.0.1:6002 > BalancerMember http://127.0.0.1:6003 > BalancerMember http://127.0.0.1:6004 > > > > BalancerMember http://127.0.0.1:7000 > BalancerMember http://127.0.0.1:7001 > BalancerMember http://127.0.0.1:7002 > BalancerMember http://127.0.0.1:7003 > BalancerMember http://127.0.0.1:7004 > > > > ProxyPass /app1/images ! > ProxyPass /app1/stylesheets ! > #continue with other static files that should be served by apache > > ProxyPass /app2/images ! > ProxyPass /app2/stylesheets ! > #continue with other static files that should be served by apache > > Alias /app1/images /path/to/public/images > Alias /app1/stylesheets /path/to/public/stylesheets > #continue with aliases for static content > > Alias /app2/images /path/to/public/images > Alias /app2/stylesheets /path/to/public/stylesheets > #continue with aliases for static content > > ProxyPass /app1 balancer://app1balancer > ProxyPass /app2 balancer://app1balancer > > > Bryan > > On Sep 7, 2006, at 4:06 PM, zer0halo wrote: > > I'm trying to set up several different Rails apps on the same domain, each > one running Mongrel. After reading all of the documentation, it's fairly > clear how to use subdomains - create several Apache virtual hosts, each of > which has a different ProxyPass and ProxyPassReverse command to redirect > from different ports (ie, 3000, 3100), and then have each Mongrel instance > (or cluster) set to the corresponding port (3000, 3100). [If this theory is > incorrect, please let me know!] > > However, what I'm trying to acheive is to host them all under the same > domain. In othe words, I would like to have > > www.domain.com/app1 > www.domain.com/app2 > > I don't know how to acheive this. Do I make each of them Virtual Hosts, > each with their own ProxyPass? (But I haven't been able to find any simple > documentation online explaining how to set a Virtual Host at > www.domain.com/app1 instead of app1.domain.com. I know fairly little about > Apache.) > > I noticed in the Mongrel documentation mention of a --prefix command and I > was wondering if that could be used to host multiple apps, but for one it's > not clear how that ties in with Apache, and secondly, the latest version of > mongrel_rails doesn't recognize that command. > > Any possibilities? Thank you. > > -- > "Impossible is nothing." > _______________________________________________ > 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 > > -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/0f26c4f7/attachment-0001.html From wyhaines at gmail.com Thu Sep 7 18:08:34 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Thu, 7 Sep 2006 16:08:34 -0600 Subject: [Mongrel] How to setup a sweeper to restart stale or hung mongrel servers In-Reply-To: References: Message-ID: On 9/7/06, Jared Brown wrote: > How do I setup a sweeper to restart stale or hung mongrel servers? If Mongel servers are hanging, doesn't that suggest some sort of very ungood bug somewhere, most likely in the application code somewhere? I know this doesn't answer your question, but a hanging server seems like it falls into the category of things that just should not happen, and that it'd be worthwhile to get to the bottom of why it is happening before working around the fact that it is happening. Kirk Haines From eoin at peelmeagrape.net Thu Sep 7 18:33:15 2006 From: eoin at peelmeagrape.net (Eoin Curran) Date: Thu, 07 Sep 2006 23:33:15 +0100 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <92b38bd50609071508l30e6ec77y9b4bdff27fd840e3@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <99E916AA-291C-439C-8B65-337BF70ADD4E@galisys.com> <92b38bd50609071508l30e6ec77y9b4bdff27fd840e3@mail.gmail.com> Message-ID: <45009E2B.4070705@peelmeagrape.net> Try putting: ActionController::AbstractRequest.relative_url_root = '/app1' in your production.rb e. zer0halo wrote: > Thanks, Bryan, I tried it and am partway there, but it's still not > working. > > http://domain/app1/controller/method > > does run the method and display the view, but the images and > stylesheets are not loading (whether or not I have a ProxyPass for the > images and stylesheets as you have below - I tried both with and > without.) Also all links to other methods fail because .... > > http://domain/app1/controller > > redirects me to: > > http://domain/controller > > Which gives be an Apache 'page not found' error. > > I presume that would be something to fix in routes.rb, but I tried a > couple of things and they didn't work. > > Thanks for any help. > > On 9/7/06, * Bryan Thompson* > wrote: > > I think this is basically how we're doing it. > > > BalancerMember http://127.0.0.1:6000 > BalancerMember http://127.0.0.1:6001 > BalancerMember http://127.0.0.1:6002 > > BalancerMember http://127.0.0.1:6003 > BalancerMember http://127.0.0.1:6004 > > > > BalancerMember http://127.0.0.1:7000 > BalancerMember http://127.0.0.1:7001 > BalancerMember http://127.0.0.1:7002 > > BalancerMember http://127.0.0.1:7003 > BalancerMember http://127.0.0.1:7004 > > > > ProxyPass /app1/images ! > ProxyPass /app1/stylesheets ! > #continue with other static files that should be served by apache > > ProxyPass /app2/images ! > ProxyPass /app2/stylesheets ! > #continue with other static files that should be served by apache > > Alias /app1/images /path/to/public/images > Alias /app1/stylesheets /path/to/public/stylesheets > > #continue with aliases for static content > > Alias /app2/images /path/to/public/images > Alias /app2/stylesheets /path/to/public/stylesheets > #continue with aliases for static content > > ProxyPass /app1 balancer://app1balancer > > ProxyPass /app2 balancer://app1balancer > > > Bryan > > On Sep 7, 2006, at 4:06 PM, zer0halo wrote: > > I'm trying to set up several different Rails apps on the same > domain, each one running Mongrel. After reading all of the > documentation, it's fairly clear how to use subdomains - create > several Apache virtual hosts, each of which has a different > ProxyPass and ProxyPassReverse command to redirect from different > ports (ie, 3000, 3100), and then have each Mongrel instance (or > cluster) set to the corresponding port (3000, 3100). [If this > theory is incorrect, please let me know!] > > However, what I'm trying to acheive is to host them all under the > same domain. In othe words, I would like to have > > www.domain.com/app1 > www.domain.com/app2 > > I don't know how to acheive this. Do I make each of them Virtual > Hosts, each with their own ProxyPass? (But I haven't been able to > find any simple documentation online explaining how to set a > Virtual Host at www.domain.com/app1 > instead of app1.domain.com . I know fairly > little about Apache.) > > I noticed in the Mongrel documentation mention of a --prefix > command and I was wondering if that could be used to host multiple > apps, but for one it's not clear how that ties in with Apache, and > secondly, the latest version of mongrel_rails doesn't recognize > that command. > > Any possibilities? Thank you. > > -- > "Impossible is nothing." > _______________________________________________ > 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 > > > > > -- > "Impossible is nothing." > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20060907/e9233264/attachment.html From shurikk at gmail.com Thu Sep 7 19:16:17 2006 From: shurikk at gmail.com (Alexander Kabanov) Date: Thu, 7 Sep 2006 16:16:17 -0700 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <45009E2B.4070705@peelmeagrape.net> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <99E916AA-291C-439C-8B65-337BF70ADD4E@galisys.com> <92b38bd50609071508l30e6ec77y9b4bdff27fd840e3@mail.gmail.com> <45009E2B.4070705@peelmeagrape.net> Message-ID: <856763c80609071616y6deb5c95o969fc6460ac26be4@mail.gmail.com> in addition to relative_url_root you need to create a symlink in your application "public" directory like ln -s . app1 after this, static content like images, css etc. will work --Alex On 9/7/06, Eoin Curran wrote: > > Try putting: > ActionController::AbstractRequest.relative_url_root = > '/app1' > in your production.rb > > e. > > zer0halo wrote: > Thanks, Bryan, I tried it and am partway there, but it's still not working. > > http://domain/app1/controller/method > > does run the method and display the view, but the images and stylesheets > are not loading (whether or not I have a ProxyPass for the images and > stylesheets as you have below - I tried both with and without.) Also all > links to other methods fail because .... > > http://domain/app1/controller > > redirects me to: > > http://domain/controller > > Which gives be an Apache 'page not found' error. > > I presume that would be something to fix in routes.rb, but I tried a couple > of things and they didn't work. > > Thanks for any help. > > > On 9/7/06, Bryan Thompson wrote: > > > > > > > > I think this is basically how we're doing it. > > > > > > > > BalancerMember http://127.0.0.1:6000 > > BalancerMember http://127.0.0.1:6001 > > BalancerMember http://127.0.0.1:6002 > > > > BalancerMember http://127.0.0.1:6003 > > BalancerMember http://127.0.0.1:6004 > > > > > > > > > > BalancerMember http://127.0.0.1:7000 > > BalancerMember http://127.0.0.1:7001 > > BalancerMember http://127.0.0.1:7002 > > > > BalancerMember http://127.0.0.1:7003 > > BalancerMember http://127.0.0.1:7004 > > > > > > > > > > ProxyPass /app1/images ! > > ProxyPass /app1/stylesheets ! > > #continue with other static files that should be served by apache > > > > > > ProxyPass /app2/images ! > > ProxyPass /app2/stylesheets ! > > #continue with other static files that should be served by apache > > > > > > Alias /app1/images /path/to/public/images > > Alias /app1/stylesheets /path/to/public/stylesheets > > > > #continue with aliases for static content > > > > > > Alias /app2/images /path/to/public/images > > Alias /app2/stylesheets /path/to/public/stylesheets > > #continue with aliases for static content > > > > > > ProxyPass /app1 balancer://app1balancer > > > > ProxyPass /app2 balancer://app1balancer > > > > > > > > > > Bryan > > > > > > > > On Sep 7, 2006, at 4:06 PM, zer0halo wrote: > > > > I'm trying to set up several different Rails apps on the same domain, each > one running Mongrel. After reading all of the documentation, it's fairly > clear how to use subdomains - create several Apache virtual hosts, each of > which has a different ProxyPass and ProxyPassReverse command to redirect > from different ports (ie, 3000, 3100), and then have each Mongrel instance > (or cluster) set to the corresponding port (3000, 3100). [If this theory is > incorrect, please let me know!] > > > > However, what I'm trying to acheive is to host them all under the same > domain. In othe words, I would like to have > > > > www.domain.com/app1 > > www.domain.com/app2 > > > > I don't know how to acheive this. Do I make each of them Virtual Hosts, > each with their own ProxyPass? (But I haven't been able to find any simple > documentation online explaining how to set a Virtual Host at > www.domain.com/app1 instead of app1.domain.com. I know fairly little about > Apache.) > > > > I noticed in the Mongrel documentation mention of a --prefix command and I > was wondering if that could be used to host multiple apps, but for one it's > not clear how that ties in with Apache, and secondly, the latest version of > mongrel_rails doesn't recognize that command. > > > > Any possibilities? Thank you. > > > > -- > > "Impossible is nothing." > > > > _______________________________________________ > > 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 > > > > > > > > -- > "Impossible is nothing." ________________________________ > > _______________________________________________ > 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 Thu Sep 7 19:26:15 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 07 Sep 2006 16:26:15 -0700 Subject: [Mongrel] LiteSpeed In-Reply-To: <20060907203512.77792.qmail@web38610.mail.mud.yahoo.com> References: <20060907203512.77792.qmail@web38610.mail.mud.yahoo.com> Message-ID: <1157671575.6720.14.camel@localhost.localdomain> On Thu, 2006-09-07 at 13:35 -0700, Joe Ruby wrote: > Yo Zed, > > Just curious -- what do you think of the LiteSpeed > server? Is it better than Lighty? Does it (gasp!) also > serve Rails apps like Mongrel? I think I read that > LiteSpeed doesn't have proxying support. I think litespeed is good stuff. I really want people who can't DIY with Mongrel and need pointy-clicky setup to go to litespeed. Or people who need more commercial support. I could even see people using Mongrel for fast development, and then pumping it onto a litespeed for their latest intranet app. My problem with the litspeed team is that they keep focusing their marketing on how fast litespeed is, but they should be focusing on how easy litespeed is to use by comparison. I'd be trying to sell it to Win32 as a way to get IIS management simplicity from a web server on a Unix platform. Better yet, call the damn thing Litespeed Enterprise Rails Application server and sell it for 10k/CPU. You're probably laughing, but remember when I was joking about the Mongrel 0.4 Enterprise Edition 1.2 release? It was obviously a joke, but I *still* got about 5 serious queries about it just because it had Enterprise in the name. Fact of the matter is most managers are morons barely aware of technology, deathly afraid for their jobs, yet they're the ones buying all the stuff. They don't give a damn about req/sec, they care about "Enterprise", "Commercial Support", and the fact that they can hire a Junior Admin rather than Ezra to get their application running. So if I can receive serious replies to a damn joke about an Enterprise edition of Mongrel, imagine what a company actually seriously offering an Enterprise Application Server could do? Hopefully they can get their heads out of their ass and beat Sun to the punch: http://www.tbray.org/ongoing/When/200x/2006/09/07/JRuby-guys I'm betting everyone $0.01 that Sun has a Rails Enterprise Server by the end of the year, or that one of their JCP Oligarchy partners claims support for it. You watch. Funny thing is they'll be running Mongrel (unless Sun changes that up too). Anyway, gonna be interesting. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Thu Sep 7 19:28:35 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 07 Sep 2006 16:28:35 -0700 Subject: [Mongrel] Upload progress and limiting file sizes In-Reply-To: <643C1991-7EC2-4E17-B0E0-130B2320A2E8@harmonypark.net> References: <643C1991-7EC2-4E17-B0E0-130B2320A2E8@harmonypark.net> Message-ID: <1157671715.6720.16.camel@localhost.localdomain> On Thu, 2006-09-07 at 22:01 +0100, Mike Evans wrote: > Thanks to all concerned with the implementation of the Upload > Progress plugin, it works really well. > > I want to limit the size of files to be uploaded to say 10Mb. Is > there any way for Mongrel to 'refuse' to upload files over a certain > size and then pass an error onto Rails in order to display feedback > to the user? I don't really want to have to upload the whole file and > then delete it if it's over the limit. > > What about the possibility of a user cancelling an upload that's > currently in progress? > > Apologies if these questions are naive, but I've always taken web > servers for granted so am very much a newb. Nope, good question. Simples way is to write a very little handler you put in front that simple checks the CONTENT_LENGTH and then redirects. Then put it in front in a -S mongrel.conf: uri "/", :handler => AhabTheMobyFileKiller.new(:path => "/file/upload"), :in_front => true Or, you could modify the stock upload handler to take another parameter. Kick back the patch if you do, other folks will probably want that. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jason at joyent.com Thu Sep 7 19:30:59 2006 From: jason at joyent.com (Jason A. Hoffman) Date: Thu, 7 Sep 2006 16:30:59 -0700 Subject: [Mongrel] LiteSpeed In-Reply-To: <1157671575.6720.14.camel@localhost.localdomain> References: <20060907203512.77792.qmail@web38610.mail.mud.yahoo.com> <1157671575.6720.14.camel@localhost.localdomain> Message-ID: On Sep 7, 2006, at 4:26 PM, Zed Shaw wrote: > I think litespeed is good stuff. I really want people who can't DIY > with Mongrel and need pointy-clicky setup to go to litespeed. Or > people > who need more commercial support. Yes I agree and consulted on their implementation. We used litespeed on php stuff like wordpress.com so had some history. > Hopefully they can get their heads out of their ass and beat Sun to > the > punch: Well. If I was a betting man ... > http://www.tbray.org/ongoing/When/200x/2006/09/07/JRuby-guys > > I'm betting everyone $0.01 that Sun has a Rails Enterprise Server > by the > end of the year, or that one of their JCP Oligarchy partners claims > support for it. You watch. You'll want to increase the amount of that bet. ;-) - J ???????????????????????????????????????????????????????????? Jason A. Hoffman, PhD | Founder, CTO, Joyent Inc. Applications => http://joyent.com/ Hosting => http://textdrive.com/ Backups => http://strongspace.com/ Weblog => http://joyeur.com/ Email => jason at joyent.com or jason at textdrive.com Mobile => (858)342-2179 ???????????????????????????????????????????????????????????? From jaredbrown at gmail.com Thu Sep 7 19:35:37 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Thu, 7 Sep 2006 19:35:37 -0400 Subject: [Mongrel] How to setup a sweeper to restart stale or hung mongrel servers In-Reply-To: References: Message-ID: What happens is the servers are waiting for their database request to come back and are in a locked state so when mod_proxy_balancer sends a request their way it gets queued and eventually apache times it out and returns a proxy error. So I am going to try and up the number of servers in the cluster and increase the proxy pass through timeout. But I was also interested in what the cluster does when a mongrel server is hung and gone stale and how it gets detected and restarted. On 9/7/06, Kirk Haines wrote: > > On 9/7/06, Jared Brown wrote: > > How do I setup a sweeper to restart stale or hung mongrel servers? > > If Mongel servers are hanging, doesn't that suggest some sort of very > ungood bug somewhere, most likely in the application code somewhere? > > I know this doesn't answer your question, but a hanging server seems > like it falls into the category of things that just should not happen, > and that it'd be worthwhile to get to the bottom of why it is > happening before working around the fact that it is happening. > > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/d86f5882/attachment.html From zedshaw at zedshaw.com Thu Sep 7 19:43:16 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 07 Sep 2006 16:43:16 -0700 Subject: [Mongrel] How to setup a sweeper to restart stale or hung mongrel servers In-Reply-To: References: Message-ID: <1157672596.6720.20.camel@localhost.localdomain> On Thu, 2006-09-07 at 16:08 -0600, Kirk Haines wrote: > On 9/7/06, Jared Brown wrote: > > How do I setup a sweeper to restart stale or hung mongrel servers? > > If Mongel servers are hanging, doesn't that suggest some sort of very > ungood bug somewhere, most likely in the application code somewhere? > > I know this doesn't answer your question, but a hanging server seems > like it falls into the category of things that just should not happen, > and that it'd be worthwhile to get to the bottom of why it is > happening before working around the fact that it is happening. Yeah, I think people are used to FCGI where zombies and broken processes are just the way it goes. I've made sure there's *tons* of debugging features in Mongrel so people can figure out what is causing the hangups and using these features we've found it's almost always one or two rails actions, that it's easy to spot with USR1 logging, and that it involves a simple rewrite or moving that code to a DRb server. But, when you're backed against a wall, having a process monitor is the only thing you can do. My favorite is monit, other folks like runit/daemon tools. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zerohalo at gmail.com Thu Sep 7 21:09:56 2006 From: zerohalo at gmail.com (zer0halo) Date: Thu, 7 Sep 2006 20:09:56 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <856763c80609071616y6deb5c95o969fc6460ac26be4@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <99E916AA-291C-439C-8B65-337BF70ADD4E@galisys.com> <92b38bd50609071508l30e6ec77y9b4bdff27fd840e3@mail.gmail.com> <45009E2B.4070705@peelmeagrape.net> <856763c80609071616y6deb5c95o969fc6460ac26be4@mail.gmail.com> Message-ID: <92b38bd50609071809g6e30159fn7d24f80aff70ce5@mail.gmail.com> Thanks, everyone for trying to help me solve this. I tried both Alex's and Eoin's changes, but alas to no avail. After applying Eoin's addition to environment.rb, the URL http://domain/app1 does correctly redirect to the default controller and method: http://domain/app1/items/index however when method 'items' redirects to method 'list', the output is http://domain/items/list (no app1) which sends the app into an endless loop. I keep getting the feeling the solution is somehow in routes.rb, but I don't know what. My routes.rb is very simple. The root route is: map.connect '', :controller => 'items' default route is the usual: map.connect ':controller/:action/:id' (I thought maybe changing the default route to map.connect'/app1/:controller/:action/:id' would work, but it gives a "recognition failed" error. -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/e3ebf8c9/attachment.html From anjan.summit at gmail.com Thu Sep 7 22:02:03 2006 From: anjan.summit at gmail.com (anjan bacchu) Date: Thu, 7 Sep 2006 19:02:03 -0700 Subject: [Mongrel] LiteSpeed In-Reply-To: <1157671575.6720.14.camel@localhost.localdomain> References: <20060907203512.77792.qmail@web38610.mail.mud.yahoo.com> <1157671575.6720.14.camel@localhost.localdomain> Message-ID: Hi Zed, On 9/7/06, Zed Shaw wrote: > > On Thu, 2006-09-07 at 13:35 -0700, Joe Ruby wrote: > > Yo Zed, > > > ....imagine what a company actually seriously offering > an Enterprise Application Server could do? > > Hopefully they can get their heads out of their ass and beat Sun to the > punch: > > http://www.tbray.org/ongoing/When/200x/2006/09/07/JRuby-guys > > I'm betting everyone $0.01 that Sun has a Rails Enterprise Server by the > end of the year, or that one of their JCP Oligarchy partners claims > support for it. You watch. > > Funny thing is they'll be running Mongrel (unless Sun changes that up > too). > > Anyway, gonna be interesting. > I'm thinking that Sun would like to have JRuby running on their existing appServers like GlassFish/Tomcat (instead of on other appServers). Sun intially wants to have developers use their tools like Netbeans or Creator/Semplice(VB for java) to develop ruby/rails code. It would not hurt us ruby/rails guys to use good IDEs(provided they are ruby/rails specific). Hopefully, sun can contribute nicely for defining the Ruby Programming Lanugage Specification so that there is a consistent implementation in the CRuby, Java Ruby and I'm almost sure C# RUBY(.NET)). Sun can contribute in terms of i18n support, threading and monitoring tools/API. Yeah, it sure's gonna be interesting. -- BR, Anjan Bacchu anjan.dev at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/5d5d50b1/attachment.html From shurikk at gmail.com Thu Sep 7 23:19:42 2006 From: shurikk at gmail.com (Alexander Kabanov) Date: Thu, 7 Sep 2006 20:19:42 -0700 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <92b38bd50609071809g6e30159fn7d24f80aff70ce5@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <99E916AA-291C-439C-8B65-337BF70ADD4E@galisys.com> <92b38bd50609071508l30e6ec77y9b4bdff27fd840e3@mail.gmail.com> <45009E2B.4070705@peelmeagrape.net> <856763c80609071616y6deb5c95o969fc6460ac26be4@mail.gmail.com> <92b38bd50609071809g6e30159fn7d24f80aff70ce5@mail.gmail.com> Message-ID: <856763c80609072019y75c0e9f3u20c3f7008ad5c8fa@mail.gmail.com> hi, I've missed parts of this conversation, but I can tell you: 1. in config/routes.rb insert line ActionController::AbstractRequest.relative_url_root = "/app1" 2. create a symlink in app1 "public": ln -s . app1 3. start mongrel or webrick ruby script/server OR mongrel_rails start -p 3000 4. connect directly to the server (without proxy) and test your application http://domain:3000/app1/ I'm 100% sure it will work have fun! --Alex On 9/7/06, zer0halo wrote: > Thanks, everyone for trying to help me solve this. I tried both Alex's and > Eoin's changes, but alas to no avail. > > After applying Eoin's addition to environment.rb, the URL > > http://domain/app1 > > does correctly redirect to the default controller and method: > > http://domain/app1/items/index > > however when method 'items' redirects to method 'list', the output is > > http://domain/items/list > > (no app1) > > which sends the app into an endless loop. > > I keep getting the feeling the solution is somehow in routes.rb, but I don't > know what. My routes.rb is very simple. The root route is: > > map.connect '', :controller => 'items' > > default route is the usual: > > map.connect ':controller/:action/:id' > > (I thought maybe changing the default route to map.connect > '/app1/:controller/:action/:id' would work, but it gives a "recognition > failed" error. > > > -- > "Impossible is nothing." > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From jaredbrown at gmail.com Thu Sep 7 23:59:13 2006 From: jaredbrown at gmail.com (Jared Brown) Date: Thu, 7 Sep 2006 23:59:13 -0400 Subject: [Mongrel] How to setup a sweeper to restart stale or hung mongrel servers In-Reply-To: <1157672596.6720.20.camel@localhost.localdomain> References: <1157672596.6720.20.camel@localhost.localdomain> Message-ID: Thanks for the response Zed. I will continue to look into the scrpt debug output. On 9/7/06, Zed Shaw wrote: > > On Thu, 2006-09-07 at 16:08 -0600, Kirk Haines wrote: > > On 9/7/06, Jared Brown wrote: > > > How do I setup a sweeper to restart stale or hung mongrel servers? > > > > If Mongel servers are hanging, doesn't that suggest some sort of very > > ungood bug somewhere, most likely in the application code somewhere? > > > > I know this doesn't answer your question, but a hanging server seems > > like it falls into the category of things that just should not happen, > > and that it'd be worthwhile to get to the bottom of why it is > > happening before working around the fact that it is happening. > > Yeah, I think people are used to FCGI where zombies and broken processes > are just the way it goes. I've made sure there's *tons* of debugging > features in Mongrel so people can figure out what is causing the hangups > and using these features we've found it's almost always one or two rails > actions, that it's easy to spot with USR1 logging, and that it involves > a simple rewrite or moving that code to a DRb server. > > But, when you're backed against a wall, having a process monitor is the > only thing you can do. > > My favorite is monit, other folks like runit/daemon tools. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Jared Brown jaredbrown at gmail.com (765) 409-0875 7001 Central Ave Indianapolis, IN 46220 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060907/b7e1d378/attachment-0001.html From jcfischer at gmail.com Fri Sep 8 09:40:25 2006 From: jcfischer at gmail.com (Jens-Christian Fischer) Date: Fri, 8 Sep 2006 15:40:25 +0200 Subject: [Mongrel] Namespace collions "cluster" Message-ID: Hi there I have a rails application that has been deployed with mongrel_cluster. My application contains a model "Cluster.rb" and now I run into namespacing problems when accessing the Cluster class (the Mongrel:Cluster module get's to try to resolve method calls which leads to a embarrassing NoMethodFound errors) I have started renaming my model, but I wonder what the "safe" way of handling namespace conflicts is. thanks Jens-Christian From nicksieger at gmail.com Fri Sep 8 10:17:32 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Fri, 8 Sep 2006 09:17:32 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> Message-ID: On 9/7/06, zer0halo wrote: > > if I was smart and knowledgeable enough I'm sure I could :-) > but I was hoping for a bit of a simpler solution. > One possibility that no one else seems to have mentioned yet is the `--prefix' option that's coming out in the 0.3.13.4 release [1]. I'm using this successfully to run multiple apps under a single domain with no modifications to Rails code. HTH, /Nick [1] http://mongrel.rubyforge.org/docs/howto.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/496dd1a3/attachment.html From kraemer at webit.de Fri Sep 8 10:51:23 2006 From: kraemer at webit.de (Jens Kraemer) Date: Fri, 8 Sep 2006 16:51:23 +0200 Subject: [Mongrel] Namespace collions "cluster" In-Reply-To: References: Message-ID: <20060908145123.GL23939@cordoba.webit.de> On Fri, Sep 08, 2006 at 03:40:25PM +0200, Jens-Christian Fischer wrote: > Hi there > > I have a rails application that has been deployed with > mongrel_cluster. My application contains a model "Cluster.rb" and now > I run into namespacing problems when accessing the Cluster class (the > Mongrel:Cluster module get's to try to resolve method calls which > leads to a embarrassing NoMethodFound errors) > > I have started renaming my model, but I wonder what the "safe" way of > handling namespace conflicts is. referencing your model class with ::Cluster could work. Jens -- webit! Gesellschaft f?r neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de Schnorrstra?e 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66 From me at seebq.com Fri Sep 8 10:57:22 2006 From: me at seebq.com (Charles Brian Quinn) Date: Fri, 8 Sep 2006 10:57:22 -0400 Subject: [Mongrel] Mass virtual hosting with mongrel In-Reply-To: <26CEB085-017A-4C1A-B987-F3C3B6C7098B@fivesquaresoftware.com> References: <3a2de0cd0609071243i7f95892fw3ffee75f62c4d9bc@mail.gmail.com> <26CEB085-017A-4C1A-B987-F3C3B6C7098B@fivesquaresoftware.com> Message-ID: <3a2de0cd0609080757i3be5014cu310b03ac764730bb@mail.gmail.com> I suppose not, but at that point I don't *think* there's anything to stop you from determining, say variables like the asset_host to hit for this particular subdomain, or the new ActiveRecord connection to some other database (assuming you've already touched one centralized one already), and even where to pull files from (an NFS share maybe). Yeah, this solution really assumes a single application - if you plan on having different versions of your app on different servers, you may want to do some other kind of load balancing to catch it before you hit the rails app and get in as far as our solution takes you. Man, lighttpd has some pretty good regex rules for handling domain, but the mod_proxy_core that you'd ultimately use to pass off to an apache 2.1 -> mongrel is being rewritten. Keep us updated, on what you find out (but I suppose this is a bit off-topic). Have you seen the railsmachine gem [1] or even our slingshot capistrano file [2] that automates vhosts pointing to different mongrel clusters? it might be possible to automate the creation of many vhosts for apache using it - and then farm off your mongrel clusters to different servers. [1] gem install railsmachine [2] http://www.slingshothosting.com/files/apache2_2_mongrel_deploy.rb cheers, On 9/7/06, John Clayton wrote: > Thanks, Charles. > > That's how we were planning on handling the DNS. What I don't think > your approach doesn't address for us is partioning the app (db, > config, roots, resources) to isolate the impact on performance and > data migration. True? > > J > > On Sep 7, 2006, at 12:43 PM, Charles Brian Quinn wrote: > > > And if this is the case, we just wrote something up on using this kind > > of "subdomain" auth as part of a key -- all one app, serving up > > different "content" / "dashboards" / "features": > > > > http://cleanair.highgroove.com/articles/2006/08/14/simplied- > > subdomain-authentication-in-ruby-on-rails > > > > The key is a DNS wildcard record: *.yourdomain.com forwarded to the > > main web/app server and rules for handling what it does. > > > > I hope we didn't mangle your question too badly, > > > > On 9/7/06, Kirk Haines wrote: > >> On 9/7/06, John Clayton wrote: > >> > >>> How can one host multiple domains with mongrel? Assuming you are > >>> mass > >>> vhosting and you also want the performance benefits of using > >>> mongrel ... > >> > >> If I remember right, you are looking at a situtation where you have a > >> single application that will have a different look and feel applied, > >> depending on the domain it is being served to, right? > >> > >> So couldn't you just set up your app to look at the SERVER_NAME and > >> choose the theme for the content appropriately? > >> > >> Then you just setup your Apache vhosts and feel all the traffic into > >> the same mongrel cluster, and you don't have to do anything at all at > >> the Mongrel level, right? You leave it to your app to be multidomain > >> aware? > >> > >> What am I missing? > >> > >> > >> Kirk Haines > >> _______________________________________________ > >> Mongrel-users mailing list > >> Mongrel-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/mongrel-users > >> > > > > > > -- > > Charles Brian Quinn > > self-promotion: www.seebq.com > > highgroove studios: www.highgroove.com > > slingshot hosting: www.slingshothosting.com > > _______________________________________________ > > 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 > -- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com From zerohalo at gmail.com Fri Sep 8 10:57:46 2006 From: zerohalo at gmail.com (zer0halo) Date: Fri, 8 Sep 2006 09:57:46 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <856763c80609072019y75c0e9f3u20c3f7008ad5c8fa@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <99E916AA-291C-439C-8B65-337BF70ADD4E@galisys.com> <92b38bd50609071508l30e6ec77y9b4bdff27fd840e3@mail.gmail.com> <45009E2B.4070705@peelmeagrape.net> <856763c80609071616y6deb5c95o969fc6460ac26be4@mail.gmail.com> <92b38bd50609071809g6e30159fn7d24f80aff70ce5@mail.gmail.com> <856763c80609072019y75c0e9f3u20c3f7008ad5c8fa@mail.gmail.com> Message-ID: <92b38bd50609080757sef97ad4p2cc94ac62f32c370@mail.gmail.com> On 9/7/06, Alexander Kabanov wrote: > > > 1. in config/routes.rb insert line > ActionController::AbstractRequest.relative_url_root = "/app1" > > 2. create a symlink in app1 "public": ln -s . app1 > > 3. start mongrel or webrick > ruby script/server OR > mongrel_rails start -p 3000 > > 4. connect directly to the server (without proxy) and test your > application > http://domain:3000/app1/ > > I'm 100% sure it will work > > Thanks, Alex. I tried the above and it does work. If I point to http://domain:3000/app1, my app works perfectly. However, when I turn on the ProxyPass in Apache to port 80, and then point to http://domain/app1 The app goes into an endless loop. Checking the logs, my app is initially correctly being routed to my default controller and method (ie: http://domain/app1/items/index). However when method 'items' redirects to method 'view_list', the application routes to: http://domain/items/view_list So basically it's not applying the /app1 prefix to all redirects. Here's a log excerpt when I access my app1 home page (just relevent lines): Processing ItemsController#index (for 172.27.6.134 at 2006-09-08 09:55:10) [GET] Parameters: {"action"=>"index", "controller"=>"items"} Redirected to http://domain/app1/items/view_list Completed in 0.03146 (31 reqs/sec) | DB: 0.00549 (17%) | 302 Found [ http://domain/items/view_list] As you can see, the last line is the problem - no app1 So it seems I'm still missing a step. My settings in my apache conf are simple: DocumentRoot /var/www # the usual other settings ProxyPass /app1 http://localhost:3000 ProxyPassReverse /app1 http://localhost:3000 ProxyPreserveHost on What am I still missing? -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/987d0cad/attachment.html From me at seebq.com Fri Sep 8 11:03:39 2006 From: me at seebq.com (Charles Brian Quinn) Date: Fri, 8 Sep 2006 11:03:39 -0400 Subject: [Mongrel] Namespace collions "cluster" In-Reply-To: <20060908145123.GL23939@cordoba.webit.de> References: <20060908145123.GL23939@cordoba.webit.de> Message-ID: <3a2de0cd0609080803w6e83b139tdab885bd6f41e51c@mail.gmail.com> Wouldn't that go find the mongrel one instead? ::Class lookups start at the root of the chain, and mongrel, loading up your application is probably in the front in this case. I am curious about this -- we had a similar conflict with a ferret_index model called Store (store.rb), and ultimately balked and renamed our model. On 9/8/06, Jens Kraemer wrote: > On Fri, Sep 08, 2006 at 03:40:25PM +0200, Jens-Christian Fischer wrote: > > Hi there > > > > I have a rails application that has been deployed with > > mongrel_cluster. My application contains a model "Cluster.rb" and now > > I run into namespacing problems when accessing the Cluster class (the > > Mongrel:Cluster module get's to try to resolve method calls which > > leads to a embarrassing NoMethodFound errors) > > > > I have started renaming my model, but I wonder what the "safe" way of > > handling namespace conflicts is. > > referencing your model class with ::Cluster could work. > > Jens > > -- > webit! Gesellschaft f?r neue Medien mbH www.webit.de > Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de > Schnorrstra?e 76 Tel +49 351 46766 0 > D-01069 Dresden Fax +49 351 46766 66 > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com From zedshaw at zedshaw.com Fri Sep 8 11:11:35 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 08 Sep 2006 08:11:35 -0700 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> Message-ID: <1157728295.9887.2.camel@localhost.localdomain> On Fri, 2006-09-08 at 09:17 -0500, Nick Sieger wrote: > On 9/7/06, zer0halo wrote: > if I was smart and knowledgeable enough I'm sure I could :-) > but I was hoping for a bit of a simpler solution. > > One possibility that no one else seems to have mentioned yet is the > `--prefix' option that's coming out in the 0.3.13.4 release [1]. I'm > using this successfully to run multiple apps under a single domain > with no modifications to Rails code. > > HTH, > > /Nick > > [1] http://mongrel.rubyforge.org/docs/howto.html Quick correction Nick, you don't need to modify Rails code as long as you slavishly utilize all the URL related helpers (like link_to()). If you had any hand coded links then those will have to change. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zerohalo at gmail.com Fri Sep 8 11:26:00 2006 From: zerohalo at gmail.com (zer0halo) Date: Fri, 8 Sep 2006 10:26:00 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <1157728295.9887.2.camel@localhost.localdomain> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> <1157728295.9887.2.camel@localhost.localdomain> Message-ID: <92b38bd50609080826v2ffedab6q62f96bf27e5e9634@mail.gmail.com> On 9/8/06, Zed Shaw wrote: > > > One possibility that no one else seems to have mentioned yet is the > > `--prefix' option that's coming out in the 0.3.13.4 release [1]. I'm > > using this successfully to run multiple apps under a single domain > > with no modifications to Rails code. > > > > HTH, > > > > /Nick > > > > [1] http://mongrel.rubyforge.org/docs/howto.html > > Quick correction Nick, you don't need to modify Rails code as long as > you slavishly utilize all the URL related helpers (like link_to()). If > you had any hand coded links then those will have to change. > > > Zed, first off, thanks for writing/releasing mongrel. Terrific app -- filled a dire need. I had read the How-To page and thought of the --prefix option, but I have the latest mongrel gem install (just did and update now to be sure) and it doesn't recognize the --prefix option or list i with start -h. If I can get the --prefix command working (I guess with the next release?), what does Apache need in that case? To summarize this thread, I'm trying to run multiple rails apps, each running their own instance of mongrel (or cluster), on the same domain, ie. http://domain/app1, http://domain/app2. I've been told to use ProxyPass in Apache to redirect from the mongrel port (ie, 3000) to port 80, but as you can see from the thread, it's not working. -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/b652d6b2/attachment-0001.html From zedshaw at zedshaw.com Fri Sep 8 11:29:06 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 08 Sep 2006 08:29:06 -0700 Subject: [Mongrel] Namespace collions "cluster" In-Reply-To: <3a2de0cd0609080803w6e83b139tdab885bd6f41e51c@mail.gmail.com> References: <20060908145123.GL23939@cordoba.webit.de> <3a2de0cd0609080803w6e83b139tdab885bd6f41e51c@mail.gmail.com> Message-ID: <1157729346.9887.5.camel@localhost.localdomain> On Fri, 2006-09-08 at 11:03 -0400, Charles Brian Quinn wrote: > Wouldn't that go find the mongrel one instead? > > ::Class lookups start at the root of the chain, and mongrel, loading > up your application is probably in the front in this case. > > I am curious about this -- we had a similar conflict with a > ferret_index model called Store (store.rb), and ultimately balked and > renamed our model. It's tough because someone has to win. Mongrel tries to stay out of the way, but there's some stuff that needs to be named certain ways for simplicity. I'm working on a few changes to make it so that the commands are in a Mongrel module, which should simplify things but it'll involve changing a few of the gem_plugins which I know will piss people off. So for now you'll have to change your model. Sorry -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jcfischer at gmail.com Fri Sep 8 11:46:07 2006 From: jcfischer at gmail.com (Jens-Christian Fischer) Date: Fri, 8 Sep 2006 17:46:07 +0200 Subject: [Mongrel] Namespace collions "cluster" In-Reply-To: <1157729346.9887.5.camel@localhost.localdomain> References: <20060908145123.GL23939@cordoba.webit.de> <3a2de0cd0609080803w6e83b139tdab885bd6f41e51c@mail.gmail.com> <1157729346.9887.5.camel@localhost.localdomain> Message-ID: <34C139A8-0838-42C2-ACB0-7DEA061D4AD1@gmail.com> > So for now you'll have to change your model. > > Sorry no problem. Thanks to a lot of unit tests the conversion went without problems From nicksieger at gmail.com Fri Sep 8 11:50:18 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Fri, 8 Sep 2006 10:50:18 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <1157728295.9887.2.camel@localhost.localdomain> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> <1157728295.9887.2.camel@localhost.localdomain> Message-ID: On 9/8/06, Zed Shaw wrote: > > > Quick correction Nick, you don't need to modify Rails code as long as > you slavishly utilize all the URL related helpers (like link_to()). If > you had any hand coded links then those will have to change. Thanks for the clarification, it's good to be aware of that point. /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/70a00313/attachment.html From shawn at brmethod.com Fri Sep 8 12:02:15 2006 From: shawn at brmethod.com (Shawn Hill) Date: Fri, 8 Sep 2006 11:02:15 -0500 Subject: [Mongrel] LiteSpeed In-Reply-To: Message-ID: <0MKp2t-1GLil62Itv-0001sj@mrelay.perfora.net> Sweet! If Sun gets involved Rails will have 3000 classes and we will need four 1000+ page books and a network engineer to deploy the "Hello, Rails!" app. I can't wait. ;) Shawn shawn at brmethod.com _____ From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of anjan bacchu Sent: Thursday, September 07, 2006 9:02 PM To: mongrel-users at rubyforge.org Subject: Re: [Mongrel] LiteSpeed Hi Zed, On 9/7/06, Zed Shaw wrote: On Thu, 2006-09-07 at 13:35 -0700, Joe Ruby wrote: > Yo Zed, > ....imagine what a company actually seriously offering an Enterprise Application Server could do? Hopefully they can get their heads out of their ass and beat Sun to the punch: http://www.tbray.org/ongoing/When/200x/2006/09/07/JRuby-guys I'm betting everyone $0.01 that Sun has a Rails Enterprise Server by the end of the year, or that one of their JCP Oligarchy partners claims support for it. You watch. Funny thing is they'll be running Mongrel (unless Sun changes that up too). Anyway, gonna be interesting. I'm thinking that Sun would like to have JRuby running on their existing appServers like GlassFish/Tomcat (instead of on other appServers). Sun intially wants to have developers use their tools like Netbeans or Creator/Semplice(VB for java) to develop ruby/rails code. It would not hurt us ruby/rails guys to use good IDEs(provided they are ruby/rails specific). Hopefully, sun can contribute nicely for defining the Ruby Programming Lanugage Specification so that there is a consistent implementation in the CRuby, Java Ruby and I'm almost sure C# RUBY(.NET)). Sun can contribute in terms of i18n support, threading and monitoring tools/API. Yeah, it sure's gonna be interesting. -- BR, Anjan Bacchu anjan.dev at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/98a0f68a/attachment.html From zedshaw at zedshaw.com Fri Sep 8 12:27:25 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 08 Sep 2006 09:27:25 -0700 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <92b38bd50609080826v2ffedab6q62f96bf27e5e9634@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> <1157728295.9887.2.camel@localhost.localdomain> <92b38bd50609080826v2ffedab6q62f96bf27e5e9634@mail.gmail.com> Message-ID: <1157732845.9887.9.camel@localhost.localdomain> On Fri, 2006-09-08 at 10:26 -0500, zer0halo wrote: > > > Zed, first off, thanks for writing/releasing mongrel. Terrific app -- > filled a dire need. > > I had read the How-To page and thought of the --prefix option, but I > have the latest mongrel gem install (just did and update now to be > sure) and it doesn't recognize the --prefix option or list i with > start -h. > Yeah, you need the pre-release, which was going to get released as official but I decided to try and fix up the naming clashes for people first. You can install the pre-release with: gem install mongrel --source=http://mongrel.rubyforge.org/releases/ And it's not built for win32 yet. > If I can get the --prefix command working (I guess with the next > release?), what does Apache need in that case? To summarize this > thread, I'm trying to run multiple rails apps, each running their own > instance of mongrel (or cluster), on the same domain, ie. > http://domain/app1, http://domain/app2. I've been told to use > ProxyPass in Apache to redirect from the mongrel port (ie, 3000) to > port 80, but as you can see from the thread, it's not working. I believe that you just have to make sure the URI path (/app2/controller/action) gets passed back to the mongrel server as-is. Don't rewrite it, just route it. If you're not sure what apache is sending mongrel, run one mongrel with -B and go look at the log/mongrel_debug/files.log and log/mongrel_debug/rails.log for clues. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zerohalo at gmail.com Fri Sep 8 12:55:40 2006 From: zerohalo at gmail.com (zer0halo) Date: Fri, 8 Sep 2006 11:55:40 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <1157732845.9887.9.camel@localhost.localdomain> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> <1157728295.9887.2.camel@localhost.localdomain> <92b38bd50609080826v2ffedab6q62f96bf27e5e9634@mail.gmail.com> <1157732845.9887.9.camel@localhost.localdomain> Message-ID: <92b38bd50609080955q54c93bcbh47ba6333d8b63950@mail.gmail.com> On 9/8/06, Zed Shaw wrote: > > You can install the pre-release with: > > gem install mongrel --source=http://mongrel.rubyforge.org/releases/ Got it. Tx. --prefix works now in that I can run by app at: http://domain:3000/app1 without any change in routes.rb However, the Apache part still doesn't work. If I go to http://domain/app1, I get nothing (no error, just blank). My log/development.log is empty which means that Rails isn't even getting that far. I believe that you just have to make sure the URI path > (/app2/controller/action) gets passed back to the mongrel server as-is. > Don't rewrite it, just route it. I'm afraid you lost me here. How do I do that? If you're not sure what apache is sending mongrel, run one mongrel with > -B and go look at the log/mongrel_debug/files.log and > log/mongrel_debug/rails.log for clues. I checked the logs and the REQUEST_PATH and PATH_INFO are both logged as /controller/action. I'm assmuing it should be /app1/controller/action, and that's the problem, but I don't know how to fix that. How? -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/d5fae4fe/attachment.html From jgeiger at gmail.com Fri Sep 8 13:03:24 2006 From: jgeiger at gmail.com (Joey Geiger) Date: Fri, 8 Sep 2006 12:03:24 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <92b38bd50609080955q54c93bcbh47ba6333d8b63950@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> <1157728295.9887.2.camel@localhost.localdomain> <92b38bd50609080826v2ffedab6q62f96bf27e5e9634@mail.gmail.com> <1157732845.9887.9.camel@localhost.localdomain> <92b38bd50609080955q54c93bcbh47ba6333d8b63950@mail.gmail.com> Message-ID: <466af3440609081003q499d4701l5b332a06d54a5d26@mail.gmail.com> ProxyPass /app1 http://127.0.0.1:3000/app1 ProxyPassReverse /app1 http://127.0.0.1:3000/app1 You need to have the proxy pass the new directory name. Now if only I could figure out how to get Apache 1.3.x to accept: ProxyPass /app/javascripts ! 1.3 doesn't like the !... On 9/8/06, zer0halo wrote: > > > On 9/8/06, Zed Shaw wrote: > > You can install the pre-release with: > > > > gem install mongrel > --source=http://mongrel.rubyforge.org/releases/ > > Got it. Tx. --prefix works now in that I can run by app at: > > http://domain:3000/app1 > > without any change in routes.rb > > However, the Apache part still doesn't work. If I go to http://domain/app1 , > I get nothing (no error, just blank). My log/development.log is empty which > means that Rails isn't even getting that far. > > > I believe that you just have to make sure the URI path > > (/app2/controller/action) gets passed back to the mongrel server as-is. > > Don't rewrite it, just route it. > > I'm afraid you lost me here. How do I do that? > > > If you're not sure what apache is sending mongrel, run one mongrel with > > -B and go look at the log/mongrel_debug/files.log and > > log/mongrel_debug/rails.log for clues. > > I checked the logs and the REQUEST_PATH and PATH_INFO are both logged as > /controller/action. I'm assmuing it should be /app1/controller/action, and > that's the problem, but I don't know how to fix that. How? > > > > -- > "Impossible is nothing." > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From zerohalo at gmail.com Fri Sep 8 13:17:48 2006 From: zerohalo at gmail.com (zer0halo) Date: Fri, 8 Sep 2006 12:17:48 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <466af3440609081003q499d4701l5b332a06d54a5d26@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> <1157728295.9887.2.camel@localhost.localdomain> <92b38bd50609080826v2ffedab6q62f96bf27e5e9634@mail.gmail.com> <1157732845.9887.9.camel@localhost.localdomain> <92b38bd50609080955q54c93bcbh47ba6333d8b63950@mail.gmail.com> <466af3440609081003q499d4701l5b332a06d54a5d26@mail.gmail.com> Message-ID: <92b38bd50609081017h783a8f68mf15f3e215165cd5e@mail.gmail.com> On 9/8/06, Joey Geiger wrote: > > ProxyPass /app1 http://127.0.0.1:3000/app1 > ProxyPassReverse /app1 http://127.0.0.1:3000/app1 > > You need to have the proxy pass the new directory name. > Victory! That was the missing piece. I had my ProxyPass as localhost:3000 instead of localhost:3000/app1. Zed, I guess that's what you meant earlier -- sorry, I'm not that smart and didn't catch it the first time around. I think it would be very helpful to have a how-to on this in the Mongrel documentation (or at least the Rails Wiki -- I'll try to add a page there), for the sake of other poor souls. The solution was simple, but like with many things in Rails, for those of us not "in the know" it's not always obvious. As a side comment, it would be great if someone wrote a book on Rails deployment, as that seems to stump a lot of people (including a long-time PHP coder friend of mine who I convinced to try Rails, which he did and found the "joy of development" but also experienced the "pain of deployment"), and is a stumbling-block to Rails adoption. There is info out there but it takes a lot of digging, googling, asking on mailing lists, etc. Some solid documentation covering various platforms and situations would be a God-send, I think. Thanks very much to all on this list who helped me with this. -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/fd989ccd/attachment-0001.html From me at seebq.com Fri Sep 8 13:39:41 2006 From: me at seebq.com (Charles Brian Quinn) Date: Fri, 8 Sep 2006 13:39:41 -0400 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <92b38bd50609081017h783a8f68mf15f3e215165cd5e@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <20060907211246.GC26183@replic.net> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> <1157728295.9887.2.camel@localhost.localdomain> <92b38bd50609080826v2ffedab6q62f96bf27e5e9634@mail.gmail.com> <1157732845.9887.9.camel@localhost.localdomain> <92b38bd50609080955q54c93bcbh47ba6333d8b63950@mail.gmail.com> <466af3440609081003q499d4701l5b332a06d54a5d26@mail.gmail.com> <92b38bd50609081017h783a8f68mf15f3e215165cd5e@mail.gmail.com> Message-ID: <3a2de0cd0609081039o1c584901l63e5b238b4b703a4@mail.gmail.com> I starred this conversation so that I would remember to add it to the Apache best practices documentation I wrote for mongrel. Consider it done (soon). http://mongrel.rubyforge.org/docs/apache.html I am waiting for pre-release to go live before adding prefix related information to the page, though. As for your books on deployment, Ezra and Zed may have you covered here soon. On 9/8/06, zer0halo wrote: > On 9/8/06, Joey Geiger wrote: > > ProxyPass /app1 http://127.0.0.1:3000/app1 > > ProxyPassReverse /app1 http://127.0.0.1:3000/app1 > > > > You need to have the proxy pass the new directory name. > > > > Victory! That was the missing piece. I had my ProxyPass as localhost:3000 > instead of localhost:3000/app1. Zed, I guess that's what you meant earlier > -- sorry, I'm not that smart and didn't catch it the first time around. > > I think it would be very helpful to have a how-to on this in the Mongrel > documentation (or at least the Rails Wiki -- I'll try to add a page there), > for the sake of other poor souls. The solution was simple, but like with > many things in Rails, for those of us not "in the know" it's not always > obvious. > > As a side comment, it would be great if someone wrote a book on Rails > deployment, as that seems to stump a lot of people (including a long-time > PHP coder friend of mine who I convinced to try Rails, which he did and > found the "joy of development" but also experienced the "pain of > deployment"), and is a stumbling-block to Rails adoption. There is info out > there but it takes a lot of digging, googling, asking on mailing lists, etc. > Some solid documentation covering various platforms and situations would be > a God-send, I think. > > Thanks very much to all on this list who helped me with this. > > -- > "Impossible is nothing." > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > -- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com From zerohalo at gmail.com Fri Sep 8 13:47:46 2006 From: zerohalo at gmail.com (zer0halo) Date: Fri, 8 Sep 2006 12:47:46 -0500 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <3a2de0cd0609081039o1c584901l63e5b238b4b703a4@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> <1157728295.9887.2.camel@localhost.localdomain> <92b38bd50609080826v2ffedab6q62f96bf27e5e9634@mail.gmail.com> <1157732845.9887.9.camel@localhost.localdomain> <92b38bd50609080955q54c93bcbh47ba6333d8b63950@mail.gmail.com> <466af3440609081003q499d4701l5b332a06d54a5d26@mail.gmail.com> <92b38bd50609081017h783a8f68mf15f3e215165cd5e@mail.gmail.com> <3a2de0cd0609081039o1c584901l63e5b238b4b703a4@mail.gmail.com> Message-ID: <92b38bd50609081047x1670ffdbk2a8eb53b7fb2d80d@mail.gmail.com> On 9/8/06, Charles Brian Quinn wrote: > > I starred this conversation so that I would remember to add it to the > Apache best practices documentation I wrote for mongrel. Consider it > done (soon). > > http://mongrel.rubyforge.org/docs/apache.html > > Awesome! -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/3e22bc51/attachment.html From anjan.summit at gmail.com Fri Sep 8 14:05:56 2006 From: anjan.summit at gmail.com (anjan bacchu) Date: Fri, 8 Sep 2006 11:05:56 -0700 Subject: [Mongrel] Multiple rails apps with Mongrel In-Reply-To: <3a2de0cd0609081039o1c584901l63e5b238b4b703a4@mail.gmail.com> References: <92b38bd50609071406s30b0b85ap6d389e47830983eb@mail.gmail.com> <92b38bd50609071421s4f5b3f87v7d464a038e864b7b@mail.gmail.com> <1157728295.9887.2.camel@localhost.localdomain> <92b38bd50609080826v2ffedab6q62f96bf27e5e9634@mail.gmail.com> <1157732845.9887.9.camel@localhost.localdomain> <92b38bd50609080955q54c93bcbh47ba6333d8b63950@mail.gmail.com> <466af3440609081003q499d4701l5b332a06d54a5d26@mail.gmail.com> <92b38bd50609081017h783a8f68mf15f3e215165cd5e@mail.gmail.com> <3a2de0cd0609081039o1c584901l63e5b238b4b703a4@mail.gmail.com> Message-ID: Hi All, On 9/8/06, Charles Brian Quinn wrote: > > I starred this conversation so that I would remember to add it to the > Apache best practices documentation I wrote for mongrel. Consider it > done (soon). > > http://mongrel.rubyforge.org/docs/apache.html > > I am waiting for pre-release to go live before adding prefix related > information to the page, though. > > As for your books on deployment, Ezra and Zed may have you covered here > soon. > > On 9/8/06, zer0halo wrote: > > On 9/8/06, Joey Geiger wrote: > > > ProxyPass /app1 http://127.0.0.1:3000/app1 > > > ProxyPassReverse /app1 http://127.0.0.1:3000/app1 > > > > > As a side comment, it would be great if someone wrote a book on Rails > > deployment, as that seems to stump a lot of people (including a > long-time > > PHP coder friend of mine who I convinced to try Rails, which he did and > > found the "joy of development" but also experienced the "pain of > > deployment"), and is a stumbling-block to Rails adoption. There is info > out > > there but it takes a lot of digging, googling, asking on mailing lists, > etc. > > Some solid documentation covering various platforms and situations would > be > > a God-send, I think. > > > > Thanks very much to all on this list who helped me with this. > > > > -- > Not sure what topics Ezra and others are gonna cover in their books on Rails deployment, but it appears that there isn't a lot of people who grok Apache deployment issues. I hope that Ezra and others will take the challenge of the following quote from http://mongrel.rubyforge.org/docs/apache.html "These instructions by Philip Hallstrom should get you started, but refer to the Apache folks for anything more complex or weird." BR, ~A -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/e910c9c7/attachment.html From random49k at gmail.com Fri Sep 8 14:24:59 2006 From: random49k at gmail.com (Mike Garey) Date: Fri, 8 Sep 2006 14:24:59 -0400 Subject: [Mongrel] Mongrel and umask for uploaded files In-Reply-To: <20060906082521.GX9513@cordoba.webit.de> References: <16a8b9140609051432s29c9fc6fsd78113ceb57f7665@mail.gmail.com> <20060906082521.GX9513@cordoba.webit.de> Message-ID: <16a8b9140609081124q26ca8726y7bdeb27fce027438@mail.gmail.com> On 9/6/06, Jens Kraemer wrote: > Hi! > On Tue, Sep 05, 2006 at 05:32:41PM -0400, Mike Garey wrote: > > So any files that are uploaded through my form are getting the following mode: > > > > -rw------- > > > > I need them to have: > > > > -rw-r--r-- > > > > I've tried setting the umask in a script file called set_umask.rb as follows: > > > > File.umask(022) > > > > and then starting mongrel using: > > > > mongrel_rails start -m config/mime.types -S set_umask.rb > > > > but it doesn't seem to change the mode that the files are created > > with.. I've also tried putting "File.umask(022)' inside > > environment.rb but that doesn't make a difference. > > I've had similar problems, in my case the umask I set was used when > uploading from Firefox/linux, but not when uploading from > Firefox/windows. Weird, but manually changing the permissions after > copying the file finally fixed this. > > File.chmod(0644, self.path_to_file) > after the File.open line should do the trick for you. thanks for the answer Jens, I ended up doing the same thing as you and it works fine now.. Thought there might be an easier way to do this, such as setting a global umask, but I guess I'll just stick to using this method until I find another way to do it. Thanks again, Mike From lapomme00 at gmail.com Fri Sep 8 14:52:42 2006 From: lapomme00 at gmail.com (Brett Walker) Date: Sat, 9 Sep 2006 02:52:42 +0800 Subject: [Mongrel] Debugging not triggered... Message-ID: I tried using the killall -USR1 mongrel_rails to check on a problem, and all I get is mongrel_rails: no process killed Nothing shows in the log. Any ideas? I'm using the latest pre-release, and a 'ps' shows my cluster is running. Cheers, Brett From g.vishnu at gmail.com Fri Sep 8 15:22:15 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Sat, 9 Sep 2006 00:52:15 +0530 Subject: [Mongrel] Debugging not triggered... In-Reply-To: References: Message-ID: sudo killall -USR1 mongrel_rails ? On 9/9/06, Brett Walker wrote: > I tried using the > > killall -USR1 mongrel_rails > > to check on a problem, and all I get is > > mongrel_rails: no process killed > > Nothing shows in the log. Any ideas? I'm using the latest > pre-release, and a 'ps' shows my cluster is running. > > Cheers, > Brett > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From zedshaw at zedshaw.com Fri Sep 8 15:30:27 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 08 Sep 2006 12:30:27 -0700 Subject: [Mongrel] Debugging not triggered... In-Reply-To: References: Message-ID: <1157743827.9887.22.camel@localhost.localdomain> On Sat, 2006-09-09 at 02:52 +0800, Brett Walker wrote: > I tried using the > > killall -USR1 mongrel_rails > > to check on a problem, and all I get is > > mongrel_rails: no process killed > > Nothing shows in the log. Any ideas? I'm using the latest > pre-release, and a 'ps' shows my cluster is running. First, make sure you got the pre-release: gem install mongrel --source=http://mongrel.rubyforge.org/releases/ Then if killall -USR1 mongrel_rails don't work you'll have to find the PID of the processes and use kill manually. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From joeat303 at yahoo.com Fri Sep 8 16:13:47 2006 From: joeat303 at yahoo.com (Joe Ruby) Date: Fri, 8 Sep 2006 13:13:47 -0700 (PDT) Subject: [Mongrel] LiteSpeed Message-ID: <20060908201347.71817.qmail@web38606.mail.mud.yahoo.com> Yeah, that was the first thought I had about the JRuby news -- here come the enterprisey people. :( Joe --- Sweet! If Sun gets involved Rails will have 3000 classes and we will need four 1000+ page books and a network engineer to deploy the "Hello, Rails!" app. I can't wait. ;) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From zedshaw at zedshaw.com Fri Sep 8 17:21:43 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 08 Sep 2006 14:21:43 -0700 Subject: [Mongrel] LiteSpeed In-Reply-To: <20060908201347.71817.qmail@web38606.mail.mud.yahoo.com> References: <20060908201347.71817.qmail@web38606.mail.mud.yahoo.com> Message-ID: <1157750503.9887.25.camel@localhost.localdomain> On Fri, 2006-09-08 at 13:13 -0700, Joe Ruby wrote: > Yeah, that was the first thought I had about the JRuby > news -- here come the enterprisey people. :( Nah, the JRuby guys are cool, if anything evil happens it'll be due to something outside their control. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From wyhaines at gmail.com Fri Sep 8 17:32:29 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Fri, 8 Sep 2006 15:32:29 -0600 Subject: [Mongrel] LiteSpeed In-Reply-To: <1157750503.9887.25.camel@localhost.localdomain> References: <20060908201347.71817.qmail@web38606.mail.mud.yahoo.com> <1157750503.9887.25.camel@localhost.localdomain> Message-ID: On 9/8/06, Zed Shaw wrote: > On Fri, 2006-09-08 at 13:13 -0700, Joe Ruby wrote: > > Yeah, that was the first thought I had about the JRuby > > news -- here come the enterprisey people. :( > > Nah, the JRuby guys are cool, if anything evil happens it'll be due to > something outside their control. Will mongrel (just mongrel, not Rails) run under JRuby right now? Kirk From nicksieger at gmail.com Fri Sep 8 17:37:38 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Fri, 8 Sep 2006 16:37:38 -0500 Subject: [Mongrel] LiteSpeed In-Reply-To: References: <20060908201347.71817.qmail@web38606.mail.mud.yahoo.com> <1157750503.9887.25.camel@localhost.localdomain> Message-ID: On 9/8/06, Kirk Haines wrote: > > On 9/8/06, Zed Shaw wrote: > > On Fri, 2006-09-08 at 13:13 -0700, Joe Ruby wrote: > > > Yeah, that was the first thought I had about the JRuby > > > news -- here come the enterprisey people. :( > > > > Nah, the JRuby guys are cool, if anything evil happens it'll be due to > > something outside their control. > > Will mongrel (just mongrel, not Rails) run under JRuby right now? Not yet, but it's getting close. An interesting development happened recently when the "Ragel guy" (sorry I don't know his name) approached Charlie and told him he had built a Ragel -> Java code generator which should help the porting process quite a bit and help it get closer to the main Mongrel codebase (at least in theory). Ask over at one of the JRuby lists [1] for more details if you're interested. /Nick [1] http://xircles.codehaus.org/projects/jruby/lists -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060908/0989422e/attachment.html From john at fivesquaresoftware.com Fri Sep 8 17:49:23 2006 From: john at fivesquaresoftware.com (John Clayton) Date: Fri, 8 Sep 2006 14:49:23 -0700 Subject: [Mongrel] Mass virtual hosting with mongrel In-Reply-To: <3a2de0cd0609080757i3be5014cu310b03ac764730bb@mail.gmail.com> References: <3a2de0cd0609071243i7f95892fw3ffee75f62c4d9bc@mail.gmail.com> <26CEB085-017A-4C1A-B987-F3C3B6C7098B@fivesquaresoftware.com> <3a2de0cd0609080757i3be5014cu310b03ac764730bb@mail.gmail.com> Message-ID: Ok, I realize this thread should really be called "hosting differently configured instances of the same app in a single mongrel instance", but that doesn't read as well ;-) I have looked over the source code for Mongrel and the various adaptations and it looks like it's not too hard to add my own classes that extend mongrel in the same ways as the rails and camping classes do, by writing my own config and handler classes. I think this is the right way to do this but I'd love to hear opinions. On Sep 8, 2006, at 7:57 AM, Charles Brian Quinn wrote: > I suppose not, but at that point I don't *think* there's anything to > stop you from determining, say variables like the asset_host to hit > for this particular subdomain, or the new ActiveRecord connection to > some other database (assuming you've already touched one centralized > one already), and even where to pull files from (an NFS share maybe). > > Yeah, this solution really assumes a single application - if you plan > on having different versions of your app on different servers, you may > want to do some other kind of load balancing to catch it before you > hit the rails app and get in as far as our solution takes you. > > Man, lighttpd has some pretty good regex rules for handling domain, > but the mod_proxy_core that you'd ultimately use to pass off to an > apache 2.1 -> mongrel is being rewritten. > > Keep us updated, on what you find out (but I suppose this is a bit > off-topic). > > Have you seen the railsmachine gem [1] or even our slingshot > capistrano file [2] that automates vhosts pointing to different > mongrel clusters? it might be possible to automate the creation of > many vhosts for apache using it - and then farm off your mongrel > clusters to different servers. I have indeed, thanks. I'm definitely drawing on these for inspiration. I think our needs for every little performance advantage is what's driving us here, which is why most stuff, though viable, just isn't fitting the bill. > > [1] gem install railsmachine > [2] http://www.slingshothosting.com/files/apache2_2_mongrel_deploy.rb > > cheers, > > On 9/7/06, John Clayton wrote: >> Thanks, Charles. >> >> That's how we were planning on handling the DNS. What I don't think >> your approach doesn't address for us is partioning the app (db, >> config, roots, resources) to isolate the impact on performance and >> data migration. True? >> >> J >> >> On Sep 7, 2006, at 12:43 PM, Charles Brian Quinn wrote: >> >>> And if this is the case, we just wrote something up on using this >>> kind >>> of "subdomain" auth as part of a key -- all one app, serving up >>> different "content" / "dashboards" / "features": >>> >>> http://cleanair.highgroove.com/articles/2006/08/14/simplied- >>> subdomain-authentication-in-ruby-on-rails >>> >>> The key is a DNS wildcard record: *.yourdomain.com forwarded to the >>> main web/app server and rules for handling what it does. >>> >>> I hope we didn't mangle your question too badly, >>> >>> On 9/7/06, Kirk Haines wrote: >>>> On 9/7/06, John Clayton wrote: >>>> >>>>> How can one host multiple domains with mongrel? Assuming you are >>>>> mass >>>>> vhosting and you also want the performance benefits of using >>>>> mongrel ... >>>> >>>> If I remember right, you are looking at a situtation where you >>>> have a >>>> single application that will have a different look and feel >>>> applied, >>>> depending on the domain it is being served to, right? >>>> >>>> So couldn't you just set up your app to look at the SERVER_NAME and >>>> choose the theme for the content appropriately? >>>> >>>> Then you just setup your Apache vhosts and feel all the traffic >>>> into >>>> the same mongrel cluster, and you don't have to do anything at >>>> all at >>>> the Mongrel level, right? You leave it to your app to be >>>> multidomain >>>> aware? >>>> >>>> What am I missing? >>>> >>>> >>>> Kirk Haines >>>> _______________________________________________ >>>> Mongrel-users mailing list >>>> Mongrel-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/mongrel-users >>>> >>> >>> >>> -- >>> Charles Brian Quinn >>> self-promotion: www.seebq.com >>> highgroove studios: www.highgroove.com >>> slingshot hosting: www.slingshothosting.com >>> _______________________________________________ >>> 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 >> > > > -- > Charles Brian Quinn > self-promotion: www.seebq.com > highgroove studios: www.highgroove.com > slingshot hosting: www.slingshothosting.com > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From zedshaw at zedshaw.com Fri Sep 8 18:24:33 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 08 Sep 2006 15:24:33 -0700 Subject: [Mongrel] Mass virtual hosting with mongrel In-Reply-To: References: <3a2de0cd0609071243i7f95892fw3ffee75f62c4d9bc@mail.gmail.com> <26CEB085-017A-4C1A-B987-F3C3B6C7098B@fivesquaresoftware.com> <3a2de0cd0609080757i3be5014cu310b03ac764730bb@mail.gmail.com> Message-ID: <1157754273.6010.3.camel@localhost.localdomain> On Fri, 2006-09-08 at 14:49 -0700, John Clayton wrote: > Ok, I realize this thread should really be called "hosting > differently configured instances of the same app in a single mongrel > instance", but that doesn't read as well ;-) > > I have looked over the source code for Mongrel and the various > adaptations and it looks like it's not too hard to add my own classes > that extend mongrel in the same ways as the rails and camping classes > do, by writing my own config and handler classes. > > I think this is the right way to do this but I'd love to hear opinions. Yep, Mongrel's designed to be easily modified and extended, and to make it easy to distribute your extensions using the GemPlugin system. Just pack you stuff in a gem and tell people how to wire it up in a -S mongrel.conf. You'll want to read through http://mongrel.rubyforge.org/rdoc/ (which closely follows the pre-releases) and to look at the various handlers in lib/mongrel/handlers.rb. You'll be much more closer to the bare metal, but you'll have more control and the ability to make things as fast as possible. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Fri Sep 8 20:33:20 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 08 Sep 2006 17:33:20 -0700 Subject: [Mongrel] Recommendation: Faster Can't Help 2 Message-ID: <1157762000.6010.23.camel@localhost.localdomain> I hope everyone is getting something out of these recommendations. Today's recommendation comes from the "Damn Common Sense" dept. of advice. Let's say you've written a really really slow rails application. Best you can get out of the thing is 2 req/sec. What can you possibly do about that? It's a common problem for new rails developers. Well, the common solution people tell you is that you need a faster server. "Buy a 4 way Xeon!" "Litespeed is 2x faster!" "See, FastCGI is sooo much faster!" I'm here to tell you a different kind of advice. The kind you really need to hear: You are a stupid moron who writes horrible code and you should fix your damn pile of crap you call software before you waste people's time and money on ass loads of hardware and software that will *not* help you anyway. Don't worry, my code sucks too--at first. Then I tell myself my code sucks, I measure it, and then I tune the living daylights out of it. Sometimes I just make a few small one line tweaks and get massive speed improvements. For example, Mongrel was sucking ass at serving files lately. I found out (through profiling) that for small stuff I could just add three lines and serve the file directly. Poof, mongrel was fast again like magic. Now I'm not saying *don't ever* buy more hardware and software. Use what works. I'm saying your first approach should be to assume you're an idiot and that there's something simple you can tune. You'd be surprised what a day of just tuning up a *working* application can get you. Sometimes it will mean you don't need to buy anything. Once you've got it to be as fast as possible without any extra help, you're at what I call "the tuning density". A good sign you're at the tuning density is when you run your program under ruby-prof you don't see any place that's dominating the execution time or that you can't change. THEN you can go buy all the stuff you need to get your application to your measurable performance metric. Ok, but there's a trap in all this: take your meds first. Programmers typically get obsessed with vanity number of performance and will spend way more time and effort than is economical trying to make their server fast. The way to avoid this is to set *measurable* targets and base them on actual needs. This does two things: 1) It tells you when to stop. 2) It tells you when you're screwed and could never meet the metrics so you can just stop working on it in the first place or change the expectations. There's a practical reason for doing this too. Mainly, you have to spend the money to test your hypothesis that the purchase will improve performance. Since your rails code is so poor there's a good chance it won't improve it, but you can't tell until you've paid the money. By doing the work to tune your app to the tuning density before your purchase you'll increase the chance that it'll help. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From carl.lerche at verizon.net Fri Sep 8 23:49:38 2006 From: carl.lerche at verizon.net (Carl Lerche) Date: Fri, 08 Sep 2006 20:49:38 -0700 Subject: [Mongrel] Recommendation: Faster Can't Help 2 In-Reply-To: <1157762000.6010.23.camel@localhost.localdomain> References: <1157762000.6010.23.camel@localhost.localdomain> Message-ID: Probably a "dumb" question, but what could be considered a good number of requests / second? -carl On Sep 8, 2006, at 5:33 PM, Zed Shaw wrote: > I hope everyone is getting something out of these recommendations. > Today's recommendation comes from the "Damn Common Sense" dept. of > advice. > > Let's say you've written a really really slow rails application. Best > you can get out of the thing is 2 req/sec. What can you possibly do > about that? It's a common problem for new rails developers. Well, > the > common solution people tell you is that you need a faster server. > "Buy > a 4 way Xeon!" "Litespeed is 2x faster!" "See, FastCGI is sooo much > faster!" > > I'm here to tell you a different kind of advice. The kind you really > need to hear: > > You are a stupid moron who writes horrible code and you should fix > your > damn pile of crap you call software before you waste people's time and > money on ass loads of hardware and software that will *not* help you > anyway. > > Don't worry, my code sucks too--at first. Then I tell myself my code > sucks, I measure it, and then I tune the living daylights out of it. > Sometimes I just make a few small one line tweaks and get massive > speed > improvements. For example, Mongrel was sucking ass at serving files > lately. I found out (through profiling) that for small stuff I could > just add three lines and serve the file directly. Poof, mongrel was > fast again like magic. > > Now I'm not saying *don't ever* buy more hardware and software. Use > what works. I'm saying your first approach should be to assume you're > an idiot and that there's something simple you can tune. You'd be > surprised what a day of just tuning up a *working* application can get > you. Sometimes it will mean you don't need to buy anything. > > Once you've got it to be as fast as possible without any extra help, > you're at what I call "the tuning density". A good sign you're at the > tuning density is when you run your program under ruby-prof you don't > see any place that's dominating the execution time or that you can't > change. > > THEN you can go buy all the stuff you need to get your application to > your measurable performance metric. > > Ok, but there's a trap in all this: take your meds first. > Programmers > typically get obsessed with vanity number of performance and will > spend > way more time and effort than is economical trying to make their > server > fast. The way to avoid this is to set *measurable* targets and base > them on actual needs. This does two things: > > 1) It tells you when to stop. > 2) It tells you when you're screwed and could never meet the > metrics so > you can just stop working on it in the first place or change the > expectations. > > There's a practical reason for doing this too. Mainly, you have to > spend the money to test your hypothesis that the purchase will improve > performance. Since your rails code is so poor there's a good > chance it > won't improve it, but you can't tell until you've paid the money. By > doing the work to tune your app to the tuning density before your > purchase you'll increase the chance that it'll help. > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From gethemant at gmail.com Sat Sep 9 01:21:12 2006 From: gethemant at gmail.com (hemant) Date: Sat, 9 Sep 2006 10:51:12 +0530 Subject: [Mongrel] Recommendation: Faster Can't Help 2 In-Reply-To: References: <1157762000.6010.23.camel@localhost.localdomain> Message-ID: " Best you can get out of the thing is 2 req/sec " On 9/9/06, Carl Lerche wrote: > > Probably a "dumb" question, but what could be considered a good > number of requests / second? > > -carl > > On Sep 8, 2006, at 5:33 PM, Zed Shaw wrote: > > > I hope everyone is getting something out of these recommendations. > > Today's recommendation comes from the "Damn Common Sense" dept. of > > advice. > > > > Let's say you've written a really really slow rails application. Best > > you can get out of the thing is 2 req/sec. What can you possibly do > > about that? It's a common problem for new rails developers. Well, > > the > > common solution people tell you is that you need a faster server. > > "Buy > > a 4 way Xeon!" "Litespeed is 2x faster!" "See, FastCGI is sooo much > > faster!" > > > > I'm here to tell you a different kind of advice. The kind you really > > need to hear: > > > > You are a stupid moron who writes horrible code and you should fix > > your > > damn pile of crap you call software before you waste people's time and > > money on ass loads of hardware and software that will *not* help you > > anyway. > > > > Don't worry, my code sucks too--at first. Then I tell myself my code > > sucks, I measure it, and then I tune the living daylights out of it. > > Sometimes I just make a few small one line tweaks and get massive > > speed > > improvements. For example, Mongrel was sucking ass at serving files > > lately. I found out (through profiling) that for small stuff I could > > just add three lines and serve the file directly. Poof, mongrel was > > fast again like magic. > > > > Now I'm not saying *don't ever* buy more hardware and software. Use > > what works. I'm saying your first approach should be to assume you're > > an idiot and that there's something simple you can tune. You'd be > > surprised what a day of just tuning up a *working* application can get > > you. Sometimes it will mean you don't need to buy anything. > > > > Once you've got it to be as fast as possible without any extra help, > > you're at what I call "the tuning density". A good sign you're at the > > tuning density is when you run your program under ruby-prof you don't > > see any place that's dominating the execution time or that you can't > > change. > > > > THEN you can go buy all the stuff you need to get your application to > > your measurable performance metric. > > > > Ok, but there's a trap in all this: take your meds first. > > Programmers > > typically get obsessed with vanity number of performance and will > > spend > > way more time and effort than is economical trying to make their > > server > > fast. The way to avoid this is to set *measurable* targets and base > > them on actual needs. This does two things: > > > > 1) It tells you when to stop. > > 2) It tells you when you're screwed and could never meet the > > metrics so > > you can just stop working on it in the first place or change the > > expectations. > > > > There's a practical reason for doing this too. Mainly, you have to > > spend the money to test your hypothesis that the purchase will improve > > performance. Since your rails code is so poor there's a good > > chance it > > won't improve it, but you can't tell until you've paid the money. By > > doing the work to tune your app to the tuning density before your > > purchase you'll increase the chance that it'll help. > > > > -- > > Zed A. Shaw > > http://www.zedshaw.com/ > > http://mongrel.rubyforge.org/ > > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > > > _______________________________________________ > > 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 > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060909/5687dc5b/attachment-0001.html From john at fivesquaresoftware.com Sat Sep 9 02:14:02 2006 From: john at fivesquaresoftware.com (John Clayton) Date: Fri, 8 Sep 2006 23:14:02 -0700 Subject: [Mongrel] Mass virtual hosting with mongrel In-Reply-To: <1157754273.6010.3.camel@localhost.localdomain> References: <3a2de0cd0609071243i7f95892fw3ffee75f62c4d9bc@mail.gmail.com> <26CEB085-017A-4C1A-B987-F3C3B6C7098B@fivesquaresoftware.com> <3a2de0cd0609080757i3be5014cu310b03ac764730bb@mail.gmail.com> <1157754273.6010.3.camel@localhost.localdomain> Message-ID: <46CF32EF-5073-4756-BA7D-31D2315F5C3C@fivesquaresoftware.com> Cool, thanks Zed. On Sep 8, 2006, at 3:24 PM, Zed Shaw wrote: > On Fri, 2006-09-08 at 14:49 -0700, John Clayton wrote: >> Ok, I realize this thread should really be called "hosting >> differently configured instances of the same app in a single mongrel >> instance", but that doesn't read as well ;-) >> >> I have looked over the source code for Mongrel and the various >> adaptations and it looks like it's not too hard to add my own classes >> that extend mongrel in the same ways as the rails and camping classes >> do, by writing my own config and handler classes. >> >> I think this is the right way to do this but I'd love to hear >> opinions. > > Yep, Mongrel's designed to be easily modified and extended, and to > make > it easy to distribute your extensions using the GemPlugin system. > Just > pack you stuff in a gem and tell people how to wire it up in a -S > mongrel.conf. > > You'll want to read through http://mongrel.rubyforge.org/rdoc/ (which > closely follows the pre-releases) and to look at the various > handlers in > lib/mongrel/handlers.rb. > > You'll be much more closer to the bare metal, but you'll have more > control and the ability to make things as fast as possible. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From gethemant at gmail.com Sat Sep 9 09:14:13 2006 From: gethemant at gmail.com (hemant) Date: Sat, 9 Sep 2006 18:44:13 +0530 Subject: [Mongrel] what should be correct .conf file for being served by apache for static content In-Reply-To: References: <1157634008.27180.2.camel@localhost.localdomain> Message-ID: "Also, if you stop Mongrel, then try to serve one of your static files, you can tell for sure whether Apache is serving it or not" To all those folks out there...who are using ProxyPass and ProxyPassReverse statements for forwarding requests to the proxy....the above tests fails, and hence....I am not sure, if Apache serves static pages, if you are using ProxyPass and ProxyPassReverse. On 9/7/06, Brett Walker wrote: > > Well, I was getting a '(13)Permission denied: ', but the permissions > on my rails directory were fine. It was one of the parent directories > that were wrong, and it took me awhile to figure that out. Maybe I'm > just too much of a newbie. > > On 9/7/06, Zed Shaw wrote: > > On Thu, 2006-09-07 at 20:37 +0800, Brett Walker wrote: > > > Hemant, > > > > > > I went through this same issue a couple of days ago. I had it > > > configured just like you do, and thought Apache was serving the static > > > files. Took me half a day to figure out the problem. > > > > > > My problem ended up being the permissions on the base directory. Was > > > serving my app from a subdir in my home directory, and it didn't have > > > the correct permission for the apache process to read it. I did a > > > > > > chmod 755 /home/myuser > > > > > > and suddenly Apache could server the static files. > > > > > > Also, if you stop Mongrel, then try to serve one of your static files, > > > you can tell for sure whether Apache is serving it or not. > > > > Hmmm, I might add that to the FAQ. Weird that apache wouldn't consider > > that an error. > > > > > > -- > > Zed A. Shaw > > http://www.zedshaw.com/ > > http://mongrel.rubyforge.org/ > > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > > > _______________________________________________ > > 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 > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060909/ad213411/attachment.html From kraemer at webit.de Sat Sep 9 09:36:31 2006 From: kraemer at webit.de (Jens Kraemer) Date: Sat, 9 Sep 2006 15:36:31 +0200 Subject: [Mongrel] what should be correct .conf file for being served by apache for static content In-Reply-To: References: <1157634008.27180.2.camel@localhost.localdomain> Message-ID: <20060909133631.GA22193@cordoba.webit.de> On Sat, Sep 09, 2006 at 06:44:13PM +0530, hemant wrote: > "Also, if you stop Mongrel, then try to serve one of your static files, > you can tell for sure whether Apache is serving it or not" > > To all those folks out there...who are using ProxyPass and ProxyPassReverse > statements for forwarding requests to the proxy....the above tests fails, > and hence....I am not sure, if Apache serves static pages, if you are using > ProxyPass and ProxyPassReverse. Yep. To conditionally forward requests to Mongrel you should use url rewrite rules instead of ProxyPass* directives: # Rewrite index to check for static RewriteRule ^/$ /index.html [QSA] # Rewrite to check for Rails cached page RewriteRule ^([^.]+)$ $1.html [QSA] # Redirect all non-static requests to cluster # translated: "if this request does not point to a file we have lying # around in our file system (the !-f part), then go ahead and let #Mongrel do it's job" RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] You can achieve the same with the Proxy* rules by explicitly excluding several directories where static files reside from being proxied, but the rewrite approach is much more elegant, imho. The snippet has been taken from the quite complex apache config example at http://mongrel.rubyforge.org/docs/apache.html Jens -- webit! Gesellschaft f?r neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de Schnorrstra?e 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66 From gethemant at gmail.com Sat Sep 9 09:52:36 2006 From: gethemant at gmail.com (hemant) Date: Sat, 9 Sep 2006 19:22:36 +0530 Subject: [Mongrel] what should be correct .conf file for being served by apache for static content In-Reply-To: <20060909133631.GA22193@cordoba.webit.de> References: <1157634008.27180.2.camel@localhost.localdomain> <20060909133631.GA22193@cordoba.webit.de> Message-ID: # Redirect all non-static requests to cluster > # translated: "if this request does not point to a file we have lying > # around in our file system (the !-f part), then go ahead and let > #Mongrel do it's job" > RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f > RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] > > You can achieve the same with the Proxy* rules by explicitly excluding > several directories where static files reside from being proxied, but > the rewrite approach is much more elegant, imho. > > The snippet has been taken from the quite complex apache config example > at http://mongrel.rubyforge.org/docs/apache.html > > Yes...i am using that. But as I have seen ProxyPass and ProxyPassReverse rules..being used(or at least, quoted as being used by so many bloggers), I wanted to point this out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060909/3e769c74/attachment.html From wyhaines at gmail.com Sat Sep 9 11:20:59 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Sat, 9 Sep 2006 09:20:59 -0600 Subject: [Mongrel] Recommendation: Faster Can't Help 2 In-Reply-To: References: <1157762000.6010.23.camel@localhost.localdomain> Message-ID: On 9/8/06, Carl Lerche wrote: > Probably a "dumb" question, but what could be considered a good > number of requests / second? That is not easily answered, since performance with any dynamic page rendering tends to be proportional to the size of the page and the amount of it that is generated via code. Kirk Haines From lapomme00 at gmail.com Sat Sep 9 11:35:34 2006 From: lapomme00 at gmail.com (Brett Walker) Date: Sat, 9 Sep 2006 23:35:34 +0800 Subject: [Mongrel] Debugging not triggered... In-Reply-To: <1157743827.9887.22.camel@localhost.localdomain> References: <1157743827.9887.22.camel@localhost.localdomain> Message-ID: I re-installed the gem, and tried sudo. Neither helped. Killing using the pid worked, as expected. But it's a pain for a cluster. What about an addtion to mongrel_cluster to toggle the debug state. mongrel_rails cluster::debug Cheers, Brett On 9/9/06, Zed Shaw wrote: > On Sat, 2006-09-09 at 02:52 +0800, Brett Walker wrote: > > I tried using the > > > > killall -USR1 mongrel_rails > > > > to check on a problem, and all I get is > > > > mongrel_rails: no process killed > > > > Nothing shows in the log. Any ideas? I'm using the latest > > pre-release, and a 'ps' shows my cluster is running. > > First, make sure you got the pre-release: > > gem install mongrel --source=http://mongrel.rubyforge.org/releases/ > > Then if killall -USR1 mongrel_rails don't work you'll have to find the > PID of the processes and use kill manually. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From gethemant at gmail.com Sat Sep 9 12:22:03 2006 From: gethemant at gmail.com (hemant) Date: Sat, 9 Sep 2006 21:52:03 +0530 Subject: [Mongrel] Debugging not triggered... In-Reply-To: References: <1157743827.9887.22.camel@localhost.localdomain> Message-ID: I may be guessing...but which log file you are trying to see. All the USR1 debugging messages would go in mongrel.log ( and on the console if you are running it in the foreground) Works as expected here.try killall -USR1 mongrel_rails as mongrel user (because thats the id i expect..you would use for running mongrel cluster, unless i am quite mistaken) On 9/9/06, Brett Walker wrote: > > I re-installed the gem, and tried sudo. Neither helped. Killing > using the pid worked, as expected. But it's a pain for a cluster. > > What about an addtion to mongrel_cluster to toggle the debug state. > > mongrel_rails cluster::debug > > Cheers, > Brett > > On 9/9/06, Zed Shaw wrote: > > On Sat, 2006-09-09 at 02:52 +0800, Brett Walker wrote: > > > I tried using the > > > > > > killall -USR1 mongrel_rails > > > > > > to check on a problem, and all I get is > > > > > > mongrel_rails: no process killed > > > > > > Nothing shows in the log. Any ideas? I'm using the latest > > > pre-release, and a 'ps' shows my cluster is running. > > > > First, make sure you got the pre-release: > > > > gem install mongrel --source=http://mongrel.rubyforge.org/releases/ > > > > Then if killall -USR1 mongrel_rails don't work you'll have to find the > > PID of the processes and use kill manually. > > > > > > -- > > Zed A. Shaw > > http://www.zedshaw.com/ > > http://mongrel.rubyforge.org/ > > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > > > _______________________________________________ > > 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 > -- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060909/bfd1b840/attachment-0001.html From joeat303 at yahoo.com Sat Sep 9 13:58:25 2006 From: joeat303 at yahoo.com (Joe Ruby) Date: Sat, 9 Sep 2006 10:58:25 -0700 (PDT) Subject: [Mongrel] Recommentation: Sessions and PStore Message-ID: <20060909175825.37285.qmail@web38612.mail.mud.yahoo.com> Uh oh! I'm sort of guilty of both #1 and #2! I'm not having any performance problems, but... I've been using the file store for sessions -- how much faster is using the database or memcached? I always thought files were quicker than the db (especially since each session gets its own file). I've been sticking the member object in a session when they login, and only updating it if they change their info. I was using the same assumption that files were quicker than the db. Joe --- 1) DON'T USE PSTORE AS A SESSION STORE! All of the people who had Mongrel processes going crazy, blocking, locking, or just generally doing bad things had a pstore as their session storage option. What happens is the pstore isn't that great when multiple processes access it, and if one Mongrel has problems pulling an object from the pstore then it'll explode. Use the file store when you develop, and use the database or memcached store in production. You should also be looking for other ways processes are sharing resources when they lock up or do weird things. Try running with just one process, and if you don't have any problems then it's a resource locking problem (most likely). 2) DON'T STORE COMPLEX OBJECTS IN THE SESSION! This especially goes for you Java people who think the session store is a temporary database. The session really only works for simple types like integers, strings, etc. You *must* follow the mantra of "Share Nothing" and either store everything in the database or use form fields and GET parameters to make it stateless. As I've said repeatedly, "If rails-core don't do it, you don't do it." Rails-core does not do this. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tom at onidle.com Sat Sep 9 16:06:45 2006 From: tom at onidle.com (Tom Brice) Date: Sat, 09 Sep 2006 15:06:45 -0500 Subject: [Mongrel] what should be correct .conf file for being served by apache for static content In-Reply-To: <20060909133631.GA22193@cordoba.webit.de> Message-ID: On 9/9/06 8:36 AM, Jens Kraemer wrote: > To conditionally forward requests to Mongrel you should use url > rewrite rules instead of ProxyPass* directives: > > # Rewrite index to check for static > RewriteRule ^/$ /index.html [QSA] > > # Rewrite to check for Rails cached page > RewriteRule ^([^.]+)$ $1.html [QSA] > > # Redirect all non-static requests to cluster > # translated: "if this request does not point to a file we have lying > # around in our file system (the !-f part), then go ahead and let > #Mongrel do it's job" > RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f > RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] > > You can achieve the same with the Proxy* rules by explicitly excluding > several directories where static files reside from being proxied, but > the rewrite approach is much more elegant, imho. > > The snippet has been taken from the quite complex apache config example > at http://mongrel.rubyforge.org/docs/apache.html Jens, Just wanted to thank you for annotating this. Very helpful to know how these rules work. Tom From zedshaw at zedshaw.com Sat Sep 9 17:19:13 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sat, 09 Sep 2006 14:19:13 -0700 Subject: [Mongrel] Recommentation: Sessions and PStore In-Reply-To: <20060909175825.37285.qmail@web38612.mail.mud.yahoo.com> References: <20060909175825.37285.qmail@web38612.mail.mud.yahoo.com> Message-ID: <1157836753.6142.9.camel@localhost.localdomain> On Sat, 2006-09-09 at 10:58 -0700, Joe Ruby wrote: > Uh oh! I'm sort of guilty of both #1 and #2! I'm not > having any performance problems, but... > > I've been using the file store for sessions -- how > much faster is using the database or memcached? I > always thought files were quicker than the db > (especially since each session gets its own file). > > I've been sticking the member object in a session when > they login, and only updating it if they change their > info. I was using the same assumption that files were > quicker than the db. Well, two points here. First, if you're going to store this member object in the database using session, why just skip the middle man and store it in the database directly? Session is slower than database for any sort of complex objects because it has to marshal/unmarshal while the AR system can use delta storage and other tricks (and even memcache caching). Second, have you tested this hypothesis? Write a simple benchmarking rails action that stores/retrieves a bunch of random member objects from the database and then from your chosen session store. I found that storing small stuff like strings, numbers, etc. is faster, but that any complex types are nasty slow. So, test it first, use the database or memcache if session storage is faster (for stability), and use the database by default in general. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From hutch at recursive.ca Sun Sep 10 09:17:04 2006 From: hutch at recursive.ca (Bob Hutchison) Date: Sun, 10 Sep 2006 09:17:04 -0400 Subject: [Mongrel] what should be correct .conf file for being served by apache for static content In-Reply-To: References: <1157634008.27180.2.camel@localhost.localdomain> Message-ID: <39CCF45B-BE7F-45F9-B16E-94DDE59289C1@recursive.ca> On Sep 9, 2006, at 9:14 AM, hemant wrote: > "Also, if you stop Mongrel, then try to serve one of your static > files, > you can tell for sure whether Apache is serving it or not" > > To all those folks out there...who are using ProxyPass and > ProxyPassReverse > statements for forwarding requests to the proxy....the above tests > fails, > and hence....I am not sure, if Apache serves static pages, if you > are using > ProxyPass and ProxyPassReverse. Hmm. It works for me. Cheers, Bob ---- Bob Hutchison -- blogs at Recursive Design Inc. -- Raconteur -- xampl for Ruby -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060910/70bf11f4/attachment.html From carl.lerche at verizon.net Sun Sep 10 16:57:16 2006 From: carl.lerche at verizon.net (Carl Lerche) Date: Sun, 10 Sep 2006 13:57:16 -0700 Subject: [Mongrel] Recommendation: Faster Can't Help 2 In-Reply-To: <1157762000.6010.23.camel@localhost.localdomain> References: <1157762000.6010.23.camel@localhost.localdomain> Message-ID: <9ED48E2C-BEEF-4222-96E6-0F5C5FC6B9E1@verizon.net> Also, is there any documentation or tutorials out there on the best way to use something like ruby-prof to tune a rails app? I just kind of have been including profiler code to tune various sections and what not that I knew were slower. Most of my applications aren't incredibly complex so I know that the main points with them are to watch for bad SQL queries and not to instantiate too many objects from these queries. But, when I'm working on a really complex web app, should I launch mongrel with ruby-prof and kind of test the whole thing or should I keep working on tuning specific parts? In short, all my tuning abilities have come from just messing around and using my own logic (for better or worse) as to how I should go about tuning. Are there any resources for me to better improve my ability at tuning apps? Thanks, -carl On Sep 8, 2006, at 5:33 PM, Zed Shaw wrote: > Once you've got it to be as fast as possible without any extra help, > you're at what I call "the tuning density". A good sign you're at the > tuning density is when you run your program under ruby-prof you don't > see any place that's dominating the execution time or that you can't > change. From andrew at sophrinix.com Sun Sep 10 22:23:20 2006 From: andrew at sophrinix.com (=?iso-8859-1?Q?andrew?=) Date: Sun, 10 Sep 2006 20:23:20 -0600 Subject: [Mongrel] fckeditor works, but i cant get my buttons back... Message-ID: <20060911022320.28598.qmail@server285.com> I am going to bet this is a mongrel issue,because this doesn't happen under webrick. Anyway, I was able to get fckeditor: http://www.fckeditor.net/ to work under rails: http://www.joshuamcharles.com/xhtml/fckrails.php i even saw the part about adding "1. Adding a YAML configuration file. For example, create $(RAILS_ROOT)/config/mongrel_mime.yml with the contents: xml: "text/xml" 2. When starting mongrel_rails, add the configuration file using the "-m" option, e.g.: mongrel_rails start -m config/mongrel_mime.yml" and that gives me a text box when i translate that to mongrel_cluster.yml ad a config: mongrel_mime.yml line to it. The issue now is I ONLY get a textbox that renders html it back. I can't get my buttons like font,style, color,etc back. I have checked this all under webrick and its a go, but not under a 3 node mongrel cluster. Anyone have any ideas? Thanks. Andrew From gethemant at gmail.com Mon Sep 11 03:17:04 2006 From: gethemant at gmail.com (hemant) Date: Mon, 11 Sep 2006 12:47:04 +0530 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: <8d9b3d920609050138p36217284qecb2bdcc6518870e@mail.gmail.com> References: <1157413171.6217.12.camel@localhost.localdomain> <1157414917.6353.2.camel@localhost.localdomain> <8d9b3d920609050138p36217284qecb2bdcc6518870e@mail.gmail.com> Message-ID: Well Zed, I i turned on USR1 debugging and all that stuff.....and I am *sometimes* get the above stated error. You might have seen...some of the my earlier code snippets where I depend upon the external data vending servers for data...and i timeout those requests..depending upon the request type. Now..that stuff is out bottleneck...mongrel threads often keep waiting there. Though I have never seen 900 threads waiting....but sometime i DO get 27 threads waiting and all that stuff. And once i get this, I will have to restart the mongrel. Basically I am going to further optimise my code..but I would really like to know, whats the following error: Tue Sep 05 03:56:40 IST 2006: ERROR: Transport endpoint is not connected - > getpeername(2) > Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not connected - > getpeername(2) > Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not connected - > getpeername(2) > Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not connected - > getpeername(2) > Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not connected - > getpeername(2) Just tell me...when exactly mongrel throws this error? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060911/13a4273e/attachment-0001.html From gethemant at gmail.com Mon Sep 11 03:32:49 2006 From: gethemant at gmail.com (hemant) Date: Mon, 11 Sep 2006 13:02:49 +0530 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: References: <1157413171.6217.12.camel@localhost.localdomain> <1157414917.6353.2.camel@localhost.localdomain> <8d9b3d920609050138p36217284qecb2bdcc6518870e@mail.gmail.com> Message-ID: On 9/11/06, hemant wrote: > > > Well Zed, > > I i turned on USR1 debugging and all that stuff.....and I am *sometimes* > get the above stated error. > > You might have seen...some of the my earlier code snippets where I depend > upon the external data vending servers for data...and i timeout those > requests..depending upon the request type. > > Now..that stuff is out bottleneck...mongrel threads often keep waiting > there. Though I have never seen 900 threads waiting....but sometime i DO get > 27 threads waiting and all that stuff. And once i get this, I will have to > restart the mongrel. Basically I am going to further optimise my code..but I > would really like to know, whats the following error: > > > Tue Sep 05 03:56:40 IST 2006: ERROR: Transport endpoint is not connected - > > getpeername(2) > > Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not connected > > - getpeername(2) > > Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not connected > > - getpeername(2) > > Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not connected > > - getpeername(2) > > Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoint is not connected > > - getpeername(2) > > > Just tell me...when exactly mongrel throws this error? > > > After turning on USR1 level debugging i get following errors in my logs: Mon Sep 11 13:00:17 IST 2006: ERROR: Transport endpoint is not connected - > getpeername(2) > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:567:in`peeraddr' > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:567:in`process_client' > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:673:in `run' > /usr/lib/ruby/gems/1.8/gems/mongrel- > 0.3.13.4/lib/mongrel/configurator.rb:267:in `run' > /usr/lib/ruby/gems/1.8/gems/mongrel- > 0.3.13.4/lib/mongrel/configurator.rb:266:in `run' > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:127:in`run' > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/command.rb:203:in`run' > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:231 > /usr/bin/mongrel_rails:18 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060911/bf9017d2/attachment.html From zedshaw at zedshaw.com Mon Sep 11 04:00:40 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 11 Sep 2006 01:00:40 -0700 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: References: <1157413171.6217.12.camel@localhost.localdomain> <1157414917.6353.2.camel@localhost.localdomain> <8d9b3d920609050138p36217284qecb2bdcc6518870e@mail.gmail.com> Message-ID: <1157961640.10686.1.camel@localhost.localdomain> On Mon, 2006-09-11 at 13:02 +0530, hemant wrote: > > > On 9/11/06, hemant wrote: > > > After turning on USR1 level debugging i get following errors in my > logs: > > Mon Sep 11 13:00:17 IST 2006: ERROR: Transport endpoint is not > connected - getpeername(2) > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:567:in `peeraddr' Hmmm, that is only there if there is no X_FORWARDED_FOR header from a proxy server and Mongrel has to resolve the host. It means you have a poorly setup DNS server that can't resolve fast enough so the process is getting stuck. How are is your proxy setup? -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From gethemant at gmail.com Mon Sep 11 04:40:21 2006 From: gethemant at gmail.com (hemant) Date: Mon, 11 Sep 2006 14:10:21 +0530 Subject: [Mongrel] mongrel proxies waiting endlessly In-Reply-To: <1157961640.10686.1.camel@localhost.localdomain> References: <1157413171.6217.12.camel@localhost.localdomain> <1157414917.6353.2.camel@localhost.localdomain> <8d9b3d920609050138p36217284qecb2bdcc6518870e@mail.gmail.com> <1157961640.10686.1.camel@localhost.localdomain> Message-ID: On 9/11/06, Zed Shaw wrote: > > Hmmm, that is only there if there is no X_FORWARDED_FOR header from a > proxy server and Mongrel has to resolve the host. It means you have a > poorly setup DNS server that can't resolve fast enough so the process is > getting stuck. > > How are is your proxy setup? Now this is weird...here I am talking about standalone mongrel server...which is not proxied through apache. I access the page..manually through the IP address and port (*just for development though*). Basically, all my server and rails code is there on a Ubuntu machine and we access(*use*) it through a Windows Machine. Anyway, I also have the mongrel cluster setup on the same machine, which runs in production mode and is proxied through Apache. My Proxy Configuration is, pretty default one suggested by Coda and Philip: ServerAdmin info at foobar.com DocumentRoot /var/www/webfront/public ServerName foobar.com ServerAlias *.foobar.com Options FollowSymLinks AllowOverride None Order allow,deny Allow from all RewriteEngine On # Make sure people go to www.myapp.com, not myapp.com RewriteCond %{HTTP_HOST} ^foobar.com$ [NC] RewriteRule ^(.*)$ http://www.foobar.com$1 [R=301,L] # Yes, I've read no-www.com, but my site already has much Google-Fu on # www.blah.com. Feel free to comment this out. # Uncomment for rewrite debugging #RewriteLog logs/myapp_rewrite_log #RewriteLogLevel 9 #ProxyPass / balancer://mongrel_cluster #ProxyPassReverse / balancer://mongrel_cluster ProxyPreserveHost On # Check for maintenance file and redirect all requests RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f RewriteCond %{SCRIPT_FILENAME} !maintenance.html RewriteRule ^.*$ /system/maintenance.html [L] # Rewrite index to check for static RewriteRule ^/$ /index.html [QSA] # Rewrite to check for Rails cached page RewriteRule ^([^.]+)$ $1.html [QSA] # Redirect all non-static requests to cluster RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] # Deflate AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4.0[678] no-gzip BrowserMatch bMSIE !no-gzip !gzip-only-text/html # Uncomment for deflate debugging #DeflateFilterNote Input input_info #DeflateFilterNote Output output_info #DeflateFilterNote Ratio ratio_info #LogFormat '"%r" %{output_info}n/%{input_info}n (%{ratio_info}n%%)' deflate #CustomLog logs/myapp_deflate_log deflate -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060911/09b142a3/attachment.html From eoin at peelmeagrape.net Mon Sep 11 09:29:55 2006 From: eoin at peelmeagrape.net (Eoin Curran) Date: Mon, 11 Sep 2006 14:29:55 +0100 Subject: [Mongrel] fckeditor works, but i cant get my buttons back... In-Reply-To: <20060911022320.28598.qmail@server285.com> References: <20060911022320.28598.qmail@server285.com> Message-ID: <450564D3.4030503@peelmeagrape.net> I had something similar I think - after getting the mongrel config right I had to clear the browser cache before fckeditor worked properly. Presumably the browser had cached the incorrect content type. e. andrew wrote: > I am going to bet this is a mongrel issue,because this doesn't happen > under webrick. Anyway, I was able to get fckeditor: http://www.fckeditor.net/ > to work under rails: http://www.joshuamcharles.com/xhtml/fckrails.php > i even saw the part about adding "1. Adding a YAML configuration file. For example, create > $(RAILS_ROOT)/config/mongrel_mime.yml with the contents: > > xml: "text/xml" > > 2. When starting mongrel_rails, add the configuration file using the > "-m" option, e.g.: > > mongrel_rails start -m config/mongrel_mime.yml" > > and that gives me a text box when i translate that to mongrel_cluster.yml ad a config: mongrel_mime.yml line to it. > > The issue now is I ONLY get a textbox that renders html it back. I can't get my buttons like font,style, color,etc back. I have checked this all under webrick and its a go, but not under a 3 node mongrel cluster. > > Anyone have any ideas? > > Thanks. > > Andrew > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From wyhaines at gmail.com Mon Sep 11 10:34:46 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 11 Sep 2006 08:34:46 -0600 Subject: [Mongrel] fckeditor works, but i cant get my buttons back... In-Reply-To: <450564D3.4030503@peelmeagrape.net> References: <20060911022320.28598.qmail@server285.com> <450564D3.4030503@peelmeagrape.net> Message-ID: On 9/11/06, Eoin Curran wrote: > I had something similar I think - after getting the mongrel config right > I had to clear the browser cache before fckeditor worked properly. > Presumably the browser had cached the incorrect content type. So long as the content type of the files are returned correctly, there should be no problem with FCKeditor through mongrel. I have a site working under IOWA+Mongrel that is using fckeditor in its CMS without any problem. Mongrel defines a content type for .js files: ".js" => "text/javascript", That does beg a question, though, Zed. Why text/javascript and not application/javascript? text/javascript is considered obsolete by the RFC, in favor of application/javascript. Note that Austin Zeigler's mime/types library, while it has the mime type defined in it, it does not tie it to the .js file suffix. I think this is an oversight and have emailed Austin about it, but if you use mime/types for anythng, be aware of this. Kirk Haines From jdz99 at hotmail.com Mon Sep 11 11:01:42 2006 From: jdz99 at hotmail.com (Jim Douglas) Date: Mon, 11 Sep 2006 15:01:42 +0000 Subject: [Mongrel] Safari Browser problems Message-ID: I can browse a site I developed/deployed to Apache 2.2.3/Mongrel from PC/s with Firefox/Explorer. I can't browse from Mac Safari? I checked these setting and it still doesn't work... http://docs.info.apple.com/article.html?artnum=151263 I don't know Mac's, what esle could this be? Jim From jamesludlow at gmail.com Mon Sep 11 11:10:57 2006 From: jamesludlow at gmail.com (James Ludlow) Date: Mon, 11 Sep 2006 10:10:57 -0500 Subject: [Mongrel] Safari Browser problems In-Reply-To: References: Message-ID: On 9/11/06, Jim Douglas wrote: > I can browse a site I developed/deployed to Apache 2.2.3/Mongrel from PC/s > with Firefox/Explorer. > > I can't browse from Mac Safari? What does "I can't browse" mean? Did you try Firefox on your Mac? Can you access other sites with Safari? What do you see in the log files? What errors are you seeing? The more detailed you can get, the more likely that someone will be able to help you. -- James From tom at onidle.com Mon Sep 11 11:13:36 2006 From: tom at onidle.com (Tom Brice) Date: Mon, 11 Sep 2006 10:13:36 -0500 Subject: [Mongrel] Safari Browser problems In-Reply-To: Message-ID: Jim, What exactly are you seeing when trying to access the app? Anything? If not what errors? How are you trying to reach your app (what address are you using)? Has it been deployed to a server that has a publicly available DNS record? Could it be that the Mac does not know the route to the app? Try accessing it directly via the server's IP and see if that works. Tom On 9/11/06 10:01 AM, Jim Douglas wrote: > I can browse a site I developed/deployed to Apache 2.2.3/Mongrel from PC/s > with Firefox/Explorer. > > I can't browse from Mac Safari? > > I checked these setting and it still doesn't work... > http://docs.info.apple.com/article.html?artnum=151263 > > I don't know Mac's, what esle could this be? > > Jim > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From andrew at sophrinix.com Mon Sep 11 11:19:45 2006 From: andrew at sophrinix.com (=?iso-8859-1?Q?andrew?=) Date: Mon, 11 Sep 2006 09:19:45 -0600 Subject: [Mongrel] fckeditor works, but i cant get my buttons back... Message-ID: <20060911151946.10017.qmail@server285.com> > -------Original Message------- > From: Kirk Haines > Subject: Re: [Mongrel] fckeditor works, but i cant get my buttons back... > Sent: Sep 11 '06 08:34 > > On 9/11/06, Eoin Curran wrote: > > I had something similar I think - after getting the mongrel config right > > I had to clear the browser cache before fckeditor worked properly. > > Presumably the browser had cached the incorrect content type. > > So long as the content type of the files are returned correctly, there > should be no problem with FCKeditor through mongrel. I have a site > working under IOWA+Mongrel that is using fckeditor in its CMS without > any problem. > > Mongrel defines a content type for .js files: > > ".js" => "text/javascript", Thanks. Sorry for such a basic question, but under mongrel_cluster.yml I have (obviously path to app is not literal): cwd: /path/to/app port: "8000" config: config/mongrel_mime.yml environment: production address: 127.0.0.1 pid_file: log/mongrel.pid servers: 12 I even tried dropping the config/ part. in the config/mongrel_mime.yml file i have: js: "text/javascript", xml: "text/xml" I even tried what you literally pasted initally, and that still doesn't work. Is mime handling the job of the front end webserver aka apache2 with mod_proxy_balancer or should this really "just work"tm Thanks Andrew > > That does beg a question, though, Zed. Why text/javascript and not > application/javascript? text/javascript is considered obsolete by the > RFC, in favor of application/javascript. > > Note that Austin Zeigler's mime/types library, while it has the mime > type defined in it, it does not tie it to the .js file suffix. I > think this is an oversight and have emailed Austin about it, but if > you use mime/types for anythng, be aware of this. > > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From wyhaines at gmail.com Mon Sep 11 11:33:57 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 11 Sep 2006 09:33:57 -0600 Subject: [Mongrel] fckeditor works, but i cant get my buttons back... In-Reply-To: <20060911151946.10017.qmail@server285.com> References: <20060911151946.10017.qmail@server285.com> Message-ID: On 9/11/06, andrew wrote: > in the config/mongrel_mime.yml file i have: > js: "text/javascript", > xml: "text/xml" > > I even tried what you literally pasted initally, and that still doesn't work. Oh, I just cut and pasted that from lib/mongre/handelers.rb > Is mime handling the job of the front end webserver aka apache2 with mod_proxy_balancer > or should this really "just work"tm I'm sleep and reading impaired today, so I didn't notice that you have mongrel_cluster in the mix. I'm pretty ignorant on mongrel_cluster, so I don't know how that might complicate things. However, in general, if mongrel is receiving your request for /editorpath/fckeditor.js, it should be returning the file contents with a mimetype of text/javascript or application/javascript (or even application/x-javascript). Now, your browser, when it runs this javascript, will generate another request for /editorpath/editor/fckeditor.html (probably with some query string arguments attached to it, interestingly). If that is returned to your browser, too, then you should see the editor. You can test this by using some tool to see what HTTP headers are being sent when fckeditor.js is retreived. wget -S http://servername.com/editorpath/fckeditor.js is one way. Make sure that the headers, and especially the content type look right. Kirk Haines From eoin at peelmeagrape.net Mon Sep 11 12:00:55 2006 From: eoin at peelmeagrape.net (Eoin Curran) Date: Mon, 11 Sep 2006 17:00:55 +0100 Subject: [Mongrel] fckeditor works, but i cant get my buttons back... In-Reply-To: <20060911151946.10017.qmail@server285.com> References: <20060911151946.10017.qmail@server285.com> Message-ID: <45058837.8060305@peelmeagrape.net> Do you need a dot in front of the extension? My mongrel_mime.yml has: --- .xml: text/xml .xpi: application/x-xpinstall and is working with fckeditor. e. > > in the config/mongrel_mime.yml file i have: > js: "text/javascript", > xml: "text/xml" > From pedro at pedrocr.net Mon Sep 11 12:02:27 2006 From: pedro at pedrocr.net (=?ISO-8859-1?Q?Pedro_C=F4rte-Real?=) Date: Mon, 11 Sep 2006 17:02:27 +0100 Subject: [Mongrel] Running some code right before the app is available to users In-Reply-To: <1155318666.5980.4.camel@localhost.localdomain> References: <62e8012c0608110805s51b6ce97h6488a7e30b84b04d@mail.gmail.com> <1155318666.5980.4.camel@localhost.localdomain> Message-ID: <62e8012c0609110902oec7a55qdf68301fb24c5d81@mail.gmail.com> On 8/11/06, Zed Shaw wrote: > You could put it in a mongrel.conf and just have Mongrel run it on > start-up: > > mongrel_rails start -S mongrel.conf > > (Even though it ends in .conf it's actually Ruby code that gets run > inside the Configurator.) I've only now went to deploy the app and had to deal with this. The solution you gave works but not in the way I need it to. Mongrel will start listening on the port before rails starts up. The stuff I need to run takes a few minutes so I don't want mongrel to be listening on the port before the script ends. Would you consider changing this order and making mongrel only start listening after rails has booted? That's how webrick works. Thanks, Pedro. From jdz99 at hotmail.com Mon Sep 11 12:07:03 2006 From: jdz99 at hotmail.com (Jim Douglas) Date: Mon, 11 Sep 2006 16:07:03 +0000 Subject: [Mongrel] Safari Browser problems In-Reply-To: Message-ID: >From: "James Ludlow" >Reply-To: mongrel-users at rubyforge.org >To: mongrel-users at rubyforge.org >Subject: Re: [Mongrel] Safari Browser problems >Date: Mon, 11 Sep 2006 10:10:57 -0500 > >On 9/11/06, Jim Douglas wrote: > > I can browse a site I developed/deployed to Apache 2.2.3/Mongrel from >PC/s > > with Firefox/Explorer. > > > > I can't browse from Mac Safari? > >What does "I can't browse" mean? >Did you try Firefox on your Mac? >Can you access other sites with Safari? >What do you see in the log files? >What errors are you seeing? > >The more detailed you can get, the more likely that someone will be >able to help you. > >-- James >_______________________________________________ >Mongrel-users mailing list >Mongrel-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/mongrel-users I can browse from a PC at a local library. The site cannot be browsed from two different Macs, two differnt friends of mine both using wireless when the can browse other site just fine. The site is up and running fine when viewed from PC's with Firefox or Explorer. I can broswe other sites I am hosting, non ROR/Ajax sites. Jim From jamesludlow at gmail.com Mon Sep 11 12:13:36 2006 From: jamesludlow at gmail.com (JDL) Date: Mon, 11 Sep 2006 11:13:36 -0500 Subject: [Mongrel] Safari Browser problems In-Reply-To: References: Message-ID: On 9/11/06, Jim Douglas wrote: > I can browse from a PC at a local library. > > The site cannot be browsed from two different Macs, two differnt friends of > mine both using wireless when the can browse other site just fine. > > The site is up and running fine when viewed from PC's with Firefox or > Explorer. > > I can broswe other sites I am hosting, non ROR/Ajax sites. What do you see in your Apache and/or Rails logs? -- James From jdz99 at hotmail.com Mon Sep 11 12:53:04 2006 From: jdz99 at hotmail.com (Jim Douglas) Date: Mon, 11 Sep 2006 16:53:04 +0000 Subject: [Mongrel] Safari Browser problems In-Reply-To: Message-ID: >From: JDL >Reply-To: mongrel-users at rubyforge.org >To: mongrel-users at rubyforge.org >Subject: Re: [Mongrel] Safari Browser problems >Date: Mon, 11 Sep 2006 11:13:36 -0500 > >On 9/11/06, Jim Douglas wrote: > > I can browse from a PC at a local library. > > > > The site cannot be browsed from two different Macs, two differnt friends >of > > mine both using wireless when the can browse other site just fine. > > > > The site is up and running fine when viewed from PC's with Firefox or > > Explorer. > > > > I can broswe other sites I am hosting, non ROR/Ajax sites. > > >What do you see in your Apache and/or Rails logs? > >-- James >_______________________________________________ >Mongrel-users mailing list >Mongrel-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/mongrel-users Apache log has nothing in it, Rails log, Processing StudioController#index (for 122.13x.1xx.2xx at 2006-09-11 10:58:25) [GET] Session ID: a8a0e62a86eed9ab2311af90b21db8a3 Parameters: {"action"=>"index", "controller"=>"studio"} Rendering within layouts/studio Rendering studio/index Completed in 0.00521 (191 reqs/sec) | Rendering: 0.00358 (68%) | DB: 0.00073 (14%) | 200 OK [http://www.mysite.com/studio] Processing Base#index (for 122.13x.1xx.2xx at 2006-09-11 10:58:26) [GET] Session ID: a8a0e62a86eed9ab2311af90b21db8a3 Parameters: {"baseRelativePath"=>"/javascripts/dojo/"} ActionController::RoutingError (Recognition failed for "/javascripts/dojo/Storage_version6.swf"): /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/routing.rb:522:in `recognition_failed' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/routing.rb:512:in `recognize!' /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispatcher.rb:38:in `dispatch' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/rails.rb:73:in `process' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:551:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:550:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:636:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:636:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:625:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:956:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:955:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:127:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/command.rb:199:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:235 /usr/bin/mongrel_rails:18 Jim From andrew at sophrinix.com Mon Sep 11 13:24:02 2006 From: andrew at sophrinix.com (=?iso-8859-1?Q?andrew?=) Date: Mon, 11 Sep 2006 11:24:02 -0600 Subject: [Mongrel] Safari Browser problems Message-ID: <20060911172402.16794.qmail@server285.com> > -------Original Message------- > From: Jim Douglas > Subject: Re: [Mongrel] Safari Browser problems > Sent: Sep 11 '06 10:53 > > >From: JDL > >Reply-To: mongrel-users at rubyforge.org > >To: mongrel-users at rubyforge.org > >Subject: Re: [Mongrel] Safari Browser problems > >Date: Mon, 11 Sep 2006 11:13:36 -0500 > > > >On 9/11/06, Jim Douglas wrote: > > > I can browse from a PC at a local library. > > > > > > The site cannot be browsed from two different Macs, two differnt friends > >of > > > mine both using wireless when the can browse other site just fine. > > > > > > The site is up and running fine when viewed from PC's with Firefox or > > > Explorer. > > > > > > I can broswe other sites I am hosting, non ROR/Ajax What happens if you get the change user agent extention for firefox and tell the site you are safari? I am able to access my apache 2.2 /w mod_proxy_balancer + mongrel cluster just fine from konqueror (which uses the same khtml engine that safari barrows from konqueror.) Andrew From zedshaw at zedshaw.com Mon Sep 11 17:31:51 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 11 Sep 2006 14:31:51 -0700 Subject: [Mongrel] fckeditor works, but i cant get my buttons back... In-Reply-To: References: <20060911022320.28598.qmail@server285.com> <450564D3.4030503@peelmeagrape.net> Message-ID: <1158010311.6073.10.camel@localhost.localdomain> On Mon, 2006-09-11 at 08:34 -0600, Kirk Haines wrote: > On 9/11/06, Eoin Curran wrote: > > I had something similar I think - after getting the mongrel config right > > I had to clear the browser cache before fckeditor worked properly. > > Presumably the browser had cached the incorrect content type. > > So long as the content type of the files are returned correctly, there > should be no problem with FCKeditor through mongrel. I have a site > working under IOWA+Mongrel that is using fckeditor in its CMS without > any problem. > > Mongrel defines a content type for .js files: > > ".js" => "text/javascript", > > That does beg a question, though, Zed. Why text/javascript and not > application/javascript? text/javascript is considered obsolete by the > RFC, in favor of application/javascript. > > Note that Austin Zeigler's mime/types library, while it has the mime > type defined in it, it does not tie it to the .js file suffix. I > think this is an oversight and have emailed Austin about it, but if > you use mime/types for anythng, be aware of this. Uh, I got that from the lighttpd mime types everyone is using. I believe I've had a few people say the few mime types mongrel has are wrong, but when they go look them up they are only "technically" wrong. In practice old ass browsers from companies in WA still don't have a clue. That being said, if you need to change it then that's why mongrel accepts the mime yaml file. Those types were just the bare minimum to get a rails app up. YMMV. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Mon Sep 11 17:43:54 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 11 Sep 2006 14:43:54 -0700 Subject: [Mongrel] fckeditor works, but i cant get my buttons back... In-Reply-To: <20060911151946.10017.qmail@server285.com> References: <20060911151946.10017.qmail@server285.com> Message-ID: <1158011034.6073.17.camel@localhost.localdomain> On Mon, 2006-09-11 at 09:19 -0600, andrew wrote: > > > -------Original Message------- > > From: Kirk Haines > > Subject: Re: [Mongrel] fckeditor works, but i cant get my buttons back... > > Sent: Sep 11 '06 08:34 > > > Thanks. Sorry for such a basic question, but under mongrel_cluster.yml > I have (obviously path to app is not literal): > cwd: /path/to/app > port: "8000" > config: config/mongrel_mime.yml > environment: production > address: 127.0.0.1 > pid_file: log/mongrel.pid > servers: 12 > I'll have to try your config out, but use absolute paths for this stuff. The relative paths were an oversite I'm trying to correct. > I even tried dropping the config/ part. > > in the config/mongrel_mime.yml file i have: > js: "text/javascript", > xml: "text/xml" > I think you need to dump what is actually getting sent back to the browser. Until then you're just guessing. Check out: http://livehttpheaders.mozdev.org/ And see what's really going on. > I even tried what you literally pasted initally, and that still doesn't work. > > Is mime handling the job of the front end webserver aka apache2 with mod_proxy_balancer > or should this really "just work"tm Yeah, that's another thing, you probably need to get this working for development, but in your production deployment you *really* do not want Mongrel handling this. It's such a waste of a perfectly good Apache server. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Mon Sep 11 17:44:54 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 11 Sep 2006 14:44:54 -0700 Subject: [Mongrel] fckeditor works, but i cant get my buttons back... In-Reply-To: <45058837.8060305@peelmeagrape.net> References: <20060911151946.10017.qmail@server285.com> <45058837.8060305@peelmeagrape.net> Message-ID: <1158011094.6073.19.camel@localhost.localdomain> On Mon, 2006-09-11 at 17:00 +0100, Eoin Curran wrote: > Do you need a dot in front of the extension? My mongrel_mime.yml has: > --- > .xml: text/xml > .xpi: application/x-xpinstall > > and is working with fckeditor. > e. Oh yeah, duh. Also, there should be a log message in log/mongrel.log yelling at you about not having a . in front of your mime types. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Mon Sep 11 17:46:58 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 11 Sep 2006 14:46:58 -0700 Subject: [Mongrel] Running some code right before the app is available to users In-Reply-To: <62e8012c0609110902oec7a55qdf68301fb24c5d81@mail.gmail.com> References: <62e8012c0608110805s51b6ce97h6488a7e30b84b04d@mail.gmail.com> <1155318666.5980.4.camel@localhost.localdomain> <62e8012c0609110902oec7a55qdf68301fb24c5d81@mail.gmail.com> Message-ID: <1158011218.6073.21.camel@localhost.localdomain> On Mon, 2006-09-11 at 17:02 +0100, Pedro C?rte-Real wrote: > On 8/11/06, Zed Shaw wrote: > > You could put it in a mongrel.conf and just have Mongrel run it on > > start-up: > > > > mongrel_rails start -S mongrel.conf > > > > (Even though it ends in .conf it's actually Ruby code that gets run > > inside the Configurator.) > > I've only now went to deploy the app and had to deal with this. The > solution you gave works but not in the way I need it to. Mongrel will > start listening on the port before rails starts up. The stuff I need > to run takes a few minutes so I don't want mongrel to be listening on > the port before the script ends. Would you consider changing this > order and making mongrel only start listening after rails has booted? > That's how webrick works. The port may be open but Mongrel isn't processing any requests. They should queue up in the OS and then when rails is loaded Mongrel will process them. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Mon Sep 11 17:48:59 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 11 Sep 2006 14:48:59 -0700 Subject: [Mongrel] Safari Browser problems In-Reply-To: References: Message-ID: <1158011339.6073.24.camel@localhost.localdomain> On Mon, 2006-09-11 at 16:53 +0000, Jim Douglas wrote: > ActionController::RoutingError (Recognition failed for > "/javascripts/dojo/Storage_version6.swf"): Jim, this means you have Mongrel serving files not Apache. I think I need to sit down and find out why people keep doing this. There's gotta be some bad documentation out there somewhere or Apache rewrite rules people are using that don't really work. Where did you get your rewrite rules from Jim? -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Mon Sep 11 18:15:31 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 11 Sep 2006 15:15:31 -0700 Subject: [Mongrel] Recommendation: Is Apache Really Serving Files? Message-ID: <1158012931.6073.38.camel@localhost.localdomain> Hi All, I've been running into quite a few people who've claimed that they have Apache (or lighttpd) serving static files, but then they paste in error messages from Mongrel that shows not only Mongrel not serving the files, but Rails is serving them. Everyone using apache should run this very simple test: 1) Setup your apache so that it point at one backend. 2) Start your application with: mongrel_rails start -e production -B 3) Hit a a few static files of different types that should be served by apache. If you see messages like this: 127.0.0.1 - [Mon, 11 Sep 2006 22:09:31 GMT] "GET /index.html HTTP/1.1" 127.0.0.1 - [Mon, 11 Sep 2006 22:09:32 GMT] "GET /javascripts/prototype.js HTTP/1.1" 127.0.0.1 - [Mon, 11 Sep 2006 22:09:33 GMT] "GET /javascripts/effects.js HTTP/1.1" 127.0.0.1 - [Mon, 11 Sep 2006 22:09:34 GMT] "GET /images/rails.png HTTP/1.1" In the console where Mongrel is running then your Apache setup isn't working and you're getting nowhere near the performance you could be getting. If this is the case, please send me your mode_rewrite rules and any proxy directives **off list** and tell me where you got them. Thanks! -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From matt at eastmedia.com Mon Sep 11 19:16:14 2006 From: matt at eastmedia.com (Matt Pelletier) Date: Mon, 11 Sep 2006 19:16:14 -0400 Subject: [Mongrel] Recommendation: Is Apache Really Serving Files? In-Reply-To: <1158012931.6073.38.camel@localhost.localdomain> References: <1158012931.6073.38.camel@localhost.localdomain> Message-ID: <79764F1E-0381-4320-ACC7-1DEBDA618D41@eastmedia.com> On Sep 11, 2006, at 6:15 PM, Zed Shaw wrote: > Hi All, > > I've been running into quite a few people who've claimed that they > have > Apache (or lighttpd) serving static files, but then they paste in > error > messages from Mongrel that shows not only Mongrel not serving the > files, > but Rails is serving them. > > Everyone using apache should run this very simple test: > > 1) Setup your apache so that it point at one backend. > 2) Start your application with: mongrel_rails start -e production -B > 3) Hit a a few static files of different types that should be > served by > apache. > > If you see messages like this: > > 127.0.0.1 - [Mon, 11 Sep 2006 22:09:31 GMT] "GET /index.html HTTP/1.1" > 127.0.0.1 - [Mon, 11 Sep 2006 22:09:32 GMT] > "GET /javascripts/prototype.js HTTP/1.1" > 127.0.0.1 - [Mon, 11 Sep 2006 22:09:33 GMT] "GET /javascripts/ > effects.js > HTTP/1.1" > 127.0.0.1 - [Mon, 11 Sep 2006 22:09:34 GMT] "GET /images/rails.png > HTTP/1.1" > > In the console where Mongrel is running then your Apache setup isn't > working and you're getting nowhere near the performance you could be > getting. I also like running $curl -I (that's a capital I as in India) (Hello Apache) $ curl -I http://somedomain.com/static/file/url/ HTTP/1.1 200 OK Date: Mon, 11 Sep 2006 23:13:05 GMT Server: Apache/2.2.3 (Unix) Last-Modified: Sun, 10 Sep 2006 18:21:52 GMT ETag: "21ac8f5-9d0a-83f57000" Accept-Ranges: bytes Content-Length: 40202 Vary: Accept-Encoding Connection: close Content-Type: text/html (Hello Mongrel) $ curl -I http://somedomain.com/go_to/rails/ HTTP/1.1 200 OK Date: Mon, 11 Sep 2006 23:13:10 GMT Server: Mongrel 0.3.13.4 Status: 200 OK Cache-Control: no-cache Content-Type: text/html; charset=utf-8 Vary: Accept-Encoding Connection: close > > If this is the case, please send me your mode_rewrite rules and any > proxy directives **off list** and tell me where you got them. > > Thanks! > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > =================== Matt Pelletier EastMedia t. 212-921-8413 x3# m. 917-902-2525 f. 212-239-4114 w. www.eastmedia.com From me at seebq.com Mon Sep 11 19:26:23 2006 From: me at seebq.com (Charles Brian Quinn) Date: Mon, 11 Sep 2006 19:26:23 -0400 Subject: [Mongrel] Recommendation: Is Apache Really Serving Files? In-Reply-To: <1158012931.6073.38.camel@localhost.localdomain> References: <1158012931.6073.38.camel@localhost.localdomain> Message-ID: <3a2de0cd0609111626q7425ae2dwff52667f9f727a59@mail.gmail.com> So here's another fun way to do it: jump on your app server: # ps auxww | grep mongrel find the processes, I'm running 5: root 13949 0.7 3.0 54188 30936 ? Sl 19:09 0:03 /usr/local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -p 8001 -a 127.0.0.1 -l /var/www/apps/xxxxx/current/log/mongrel.log -P /var/www/apps/xxxxx/current/log/mongrel.8001.pid -c /var/www/apps/xxxxx/current root 13954 0.8 3.5 60028 36464 ? Sl 19:09 0:03 /usr/local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -p 8002 -a 127.0.0.1 -l /var/www/apps/xxxxx/current/log/mongrel.log -P /var/www/apps/xxxxx/current/log/mongrel.8002.pid -c /var/www/apps/xxxxx/current root 13959 0.4 2.8 52612 29088 ? Sl 19:09 0:02 /usr/local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -p 8003 -a 127.0.0.1 -l /var/www/apps/xxxxx/current/log/mongrel.log -P /var/www/apps/xxxxx/current/log/mongrel.8003.pid -c /var/www/apps/xxxxx/current root 13963 0.7 4.2 68448 43768 ? Sl 19:09 0:03 /usr/local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -p 8004 -a 127.0.0.1 -l /var/www/apps/xxxxx/current/log/mongrel.log -P /var/www/apps/xxxxx/current/log/mongrel.8004.pid -c /var/www/apps/xxxxx/current root 13998 1.4 2.5 48740 25916 ? Sl 19:12 0:03 /usr/local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -p 8000 -a 127.0.0.1 -l /var/www/apps/xxxxx/current/log/mongrel.log -P /var/www/apps/xxxxx/current/log/mongrel.8000.pid -c /var/www/apps/xxxxx/current root 14043 0.0 0.0 4240 632 pts/0 R+ 19:16 0:00 grep mongrel now kill one (your users will love this if you're live). copy that line first # kill -9 13998 and restart it erasing the -d (daemonize option) and adding -B # /usr/local/bin/ruby /usr/local/bin/mongrel_rails start -e production -p 8000 -a 127.0.0.1 -l /var/www/apps/xxxxx/current/log/mongrel.log -P /var/www/apps/xxxxx/current/log/mongrel.8000.pid -c /var/www/apps/xxxxx/current -B ** Starting Mongrel listening at 127.0.0.1:8000 It should start up, now on the command line, and you should see dynamic requests only: xx.xx.xx.xx - [Mon, 11 Sep 2006 23:17:05 GMT] "GET /messages?group=988 HTTP/1.1" xx.xx.xx.xx - [Mon, 11 Sep 2006 23:17:14 GMT] "GET /messages/list HTTP/1.1" xx.xx.xx.xx - [Mon, 11 Sep 2006 23:17:41 GMT] "GET /articles/show/172 HTTP/1.1" xx.xx.xx.xx, xx.xx.xx.xx - [Mon, 11 Sep 2006 23:19:56 GMT] "GET /articles/show/150 HTTP/1.1" If you are just running run mongrel_rails instance and proxy passing, I think we already established that apache is just forwarding on everything to mongrel, so that's fine for testing (and fine if you just want apache to be a big ole request forwarding server), but you'll need some apache kung-fu (adding Coda's mod_rewrite rules) for not passing on static content to dirs. You'll have to steal it from the advanced setup (until I can rewrite it and test those rules with the proxy pass settings): http://mongrel.rubyforge.org/docs/apache.html hope this helps, -- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com From eule at space.ch Tue Sep 12 05:15:38 2006 From: eule at space.ch (Kaspar Schiess) Date: Tue, 12 Sep 2006 11:15:38 +0200 Subject: [Mongrel] [ANN] Mongrel Upload Progress 0.2 -- With Instructions and Examples In-Reply-To: <1157413059.6217.10.camel@localhost.localdomain> References: <1157413059.6217.10.camel@localhost.localdomain> Message-ID: <45067ABA.8010200@space.ch> Hello all, Is it just me or are the upload plugin instructions all buggy? I had to change the following bits of code: - FilesController#progress: #check is an instance method if the Singleton Mongrel::Uploads, so Uploads.instance.check instead of Uploads.check. def progress render :update do |page| @status = Mongrel::Uploads.instance.check(params[:upload_id]) page.upload_progress.update(@status['size'], @status['received']) if @status end end - Progressbar would not show at first. I had to fix the javascript at least in one place: update: function(status, statusHTML) { this.statusText.innerHTML = statusHTML; + this.statusBar.style.width = '' + Math.floor(this.statusBarWidth * status) + 'px'; - this.statusBar.style.width = Math.floor(this.statusBarWidth * status); } - Not a problem of the instructions per se, but worth mentioning: Lighttpd seems to buffer the whole upload and then send it all at once to a proxied mongrel instance behind it. So that won't give you any progress bar at all. Pound as a frontend behaves much better. I hope to be of help with this tale of experience made. Really nice work on the plugin guys, thank you a lot. Zed, thanks for Mongrel, it has given me confidence about rails deployment for the first time - have tried all other magic bullets, and most of them didn't quite work. best regards kaspar neotrivium.com - the swiss ruby shop From pedro at pedrocr.net Tue Sep 12 05:45:00 2006 From: pedro at pedrocr.net (=?ISO-8859-1?Q?Pedro_C=F4rte-Real?=) Date: Tue, 12 Sep 2006 10:45:00 +0100 Subject: [Mongrel] Running some code right before the app is available to users In-Reply-To: <1158011218.6073.21.camel@localhost.localdomain> References: <62e8012c0608110805s51b6ce97h6488a7e30b84b04d@mail.gmail.com> <1155318666.5980.4.camel@localhost.localdomain> <62e8012c0609110902oec7a55qdf68301fb24c5d81@mail.gmail.com> <1158011218.6073.21.camel@localhost.localdomain> Message-ID: <62e8012c0609120245i17020ad5o5e42bb557bf072c3@mail.gmail.com> On 9/11/06, Zed Shaw wrote: > The port may be open but Mongrel isn't processing any requests. They > should queue up in the OS and then when rails is loaded Mongrel will > process them. Yes, but that's the problem. I run an apache proxying to mongrel and when mongrel is down it shows a custom error page saying that the app is not available. If mongrel starts listening on the port apache will try to connect and hang there until it timeouts instead of giving the error page to the user. Since mongrel can't process any requests it would make more sense to only start listening on the port after rails boots. Pedro. From technoweenie at gmail.com Tue Sep 12 08:59:10 2006 From: technoweenie at gmail.com (Rick Olson) Date: Tue, 12 Sep 2006 07:59:10 -0500 Subject: [Mongrel] [ANN] Mongrel Upload Progress 0.2 -- With Instructions and Examples In-Reply-To: <45067ABA.8010200@space.ch> References: <1157413059.6217.10.camel@localhost.localdomain> <45067ABA.8010200@space.ch> Message-ID: <48fe25b0609120559j392cf5f1n6cde50b79a7cf20a@mail.gmail.com> On 9/12/06, Kaspar Schiess wrote: > Hello all, > > Is it just me or are the upload plugin instructions all buggy? I had to > change the following bits of code: > > - FilesController#progress: #check is an instance method if the > Singleton Mongrel::Uploads, so Uploads.instance.check instead of > Uploads.check. > > def progress > render :update do |page| > @status = Mongrel::Uploads.instance.check(params[:upload_id]) > page.upload_progress.update(@status['size'], @status['received']) > if @status > end > end > > - Progressbar would not show at first. I had to fix the javascript at > least in one place: > > update: function(status, statusHTML) { > this.statusText.innerHTML = statusHTML; > + this.statusBar.style.width = '' + Math.floor(this.statusBarWidth > * status) + 'px'; > - this.statusBar.style.width = Math.floor(this.statusBarWidth * > status); > } > > - Not a problem of the instructions per se, but worth mentioning: > Lighttpd seems to buffer the whole upload and then send it all at once > to a proxied mongrel instance behind it. So that won't give you any > progress bar at all. Pound as a frontend behaves much better. > > I hope to be of help with this tale of experience made. Really nice work > on the plugin guys, thank you a lot. Zed, thanks for Mongrel, it has > given me confidence about rails deployment for the first time - have > tried all other magic bullets, and most of them didn't quite work. > > best regards > kaspar > > neotrivium.com - the swiss ruby shop I don't know, I made that video with that exact code. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com From zedshaw at zedshaw.com Tue Sep 12 09:10:53 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Tue, 12 Sep 2006 06:10:53 -0700 Subject: [Mongrel] [ANN] Mongrel Upload Progress 0.2 -- With Instructions and Examples In-Reply-To: <45067ABA.8010200@space.ch> References: <1157413059.6217.10.camel@localhost.localdomain> <45067ABA.8010200@space.ch> Message-ID: <1158066653.6020.2.camel@localhost.localdomain> On Tue, 2006-09-12 at 11:15 +0200, Kaspar Schiess wrote: > Hello all, > > Is it just me or are the upload plugin instructions all buggy? I had to > change the following bits of code: > > - FilesController#progress: #check is an instance method if the > Singleton Mongrel::Uploads, so Uploads.instance.check instead of > Uploads.check. > You sure you're using the right version? You need the stuff available currently from the pre-release. So, if you didn't do: gem install mongrel mongrel_upload_progress --source=http://mongrel.rubyforge.org/releases/ Then you've got the wrong one. > - Not a problem of the instructions per se, but worth mentioning: > Lighttpd seems to buffer the whole upload and then send it all at once > to a proxied mongrel instance behind it. So that won't give you any > progress bar at all. Pound as a frontend behaves much better. > Interesting to know. I know Rick uses litespeed so I'm curious what he gets. > I hope to be of help with this tale of experience made. Really nice work > on the plugin guys, thank you a lot. Zed, thanks for Mongrel, it has > given me confidence about rails deployment for the first time - have > tried all other magic bullets, and most of them didn't quite work. Thanks Kaspar. Much appreciated. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From ezmobius at gmail.com Tue Sep 12 12:17:55 2006 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Tue, 12 Sep 2006 09:17:55 -0700 Subject: [Mongrel] Nginx conf with all the right rules for mongrel_cluster Message-ID: <4A36359E-C0B8-418F-A20C-6B2511E18D47@gmail.com> Folks- James Cox, Alexy Kovyrin and I all huddled up and got nginx working perfectly with mongrel cluster and rails page caching. So all static and cached files are served fast by nginx and anything not static gets sent to mongrel. http://brainspl.at/articles/2006/09/12/new-nginx-conf-with-rails-caching Cheers- -Ezra From g.vishnu at gmail.com Tue Sep 12 13:20:07 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Tue, 12 Sep 2006 22:50:07 +0530 Subject: [Mongrel] Nginx conf with all the right rules for mongrel_cluster In-Reply-To: <4A36359E-C0B8-418F-A20C-6B2511E18D47@gmail.com> References: <4A36359E-C0B8-418F-A20C-6B2511E18D47@gmail.com> Message-ID: Thanks, this is sweet :-) Will try this out soon. Vish On 9/12/06, Ezra Zygmuntowicz wrote: > > Folks- > > James Cox, Alexy Kovyrin and I all huddled up and got nginx > working > perfectly with mongrel cluster and rails page caching. So all static > and cached files are served fast by nginx and anything not static > gets sent to mongrel. > > http://brainspl.at/articles/2006/09/12/new-nginx-conf-with-rails-caching > > > Cheers- > -Ezra > _______________________________________________ > 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/20060912/d26c1fc4/attachment.html From zedshaw at zedshaw.com Tue Sep 12 20:01:35 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Tue, 12 Sep 2006 17:01:35 -0700 Subject: [Mongrel] Nginx conf with all the right rules for mongrel_cluster In-Reply-To: <4A36359E-C0B8-418F-A20C-6B2511E18D47@gmail.com> References: <4A36359E-C0B8-418F-A20C-6B2511E18D47@gmail.com> Message-ID: <1158105695.5918.4.camel@localhost.localdomain> On Tue, 2006-09-12 at 09:17 -0700, Ezra Zygmuntowicz wrote: > Folks- > > James Cox, Alexy Kovyrin and I all huddled up and got nginx working > perfectly with mongrel cluster and rails page caching. So all static > and cached files are served fast by nginx and anything not static > gets sent to mongrel. > > http://brainspl.at/articles/2006/09/12/new-nginx-conf-with-rails-caching Man that's sexy. I will be playing with this tonight for sure. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From pedro at pedrocr.net Wed Sep 13 07:30:02 2006 From: pedro at pedrocr.net (=?ISO-8859-1?Q?Pedro_C=F4rte-Real?=) Date: Wed, 13 Sep 2006 12:30:02 +0100 Subject: [Mongrel] Running some code right before the app is available to users In-Reply-To: <62e8012c0609120245i17020ad5o5e42bb557bf072c3@mail.gmail.com> References: <62e8012c0608110805s51b6ce97h6488a7e30b84b04d@mail.gmail.com> <1155318666.5980.4.camel@localhost.localdomain> <62e8012c0609110902oec7a55qdf68301fb24c5d81@mail.gmail.com> <1158011218.6073.21.camel@localhost.localdomain> <62e8012c0609120245i17020ad5o5e42bb557bf072c3@mail.gmail.com> Message-ID: <62e8012c0609130430j607b69ceud61bf6ba64a9e24e@mail.gmail.com> On 9/12/06, Pedro C?rte-Real wrote: > Since mongrel can't process any requests it > would make more sense to only start listening on the port after rails > boots. Do you disagree with this? Is it very hard to do? Would you consider changing the behaviour to that? Pedro. From zedshaw at zedshaw.com Wed Sep 13 09:16:41 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 13 Sep 2006 06:16:41 -0700 Subject: [Mongrel] Running some code right before the app is available to users In-Reply-To: <62e8012c0609130430j607b69ceud61bf6ba64a9e24e@mail.gmail.com> References: <62e8012c0608110805s51b6ce97h6488a7e30b84b04d@mail.gmail.com> <1155318666.5980.4.camel@localhost.localdomain> <62e8012c0609110902oec7a55qdf68301fb24c5d81@mail.gmail.com> <1158011218.6073.21.camel@localhost.localdomain> <62e8012c0609120245i17020ad5o5e42bb557bf072c3@mail.gmail.com> <62e8012c0609130430j607b69ceud61bf6ba64a9e24e@mail.gmail.com> Message-ID: <1158153401.5895.8.camel@localhost.localdomain> On Wed, 2006-09-13 at 12:30 +0100, Pedro C?rte-Real wrote: > On 9/12/06, Pedro C?rte-Real wrote: > > Since mongrel can't process any requests it > > would make more sense to only start listening on the port after rails > > boots. > > Do you disagree with this? Is it very hard to do? Would you consider > changing the behaviour to that? I think Pedro that you might have to look for another solution before you try to get me to change the core of mongrel. I'm pretty sure there are plenty of other ways to do what you need and your requirements are particular to what you do. Not brushing you off, I just have to pick where I apply my time and this change would most likely break other established plugins and things. If you get desperate then crack open the mongrel_rails, throw your code at the top and call it mongrel_pedro_rails. That's what I'd do. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jacob at jacobatzen.dk Wed Sep 13 10:00:21 2006 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Wed, 13 Sep 2006 16:00:21 +0200 Subject: [Mongrel] Mongrel spewing backtraces and nanosleeping Message-ID: <20060913140021.GA1152@nezbo.dhcp.aub.dk> Hi list, I'm seeing a couple of issues with Mongrel. I'm running FreeBSD 6.1 and have previously been told that there are known conflicts between this and Mongrel, yet I hope these issues will be resolved with time. I'm overloading Mongrel with httperf on my local workstation. Mongrel is started directly with the mongrel_rails command and there is only one mongrel running. Soon I will start seeing: Server overloaded with N processors (M max). Dropping connection. Wed Sep 13 00:03:05 CEST 2006: Reaping N threads for slow workers because of 'max processors' Now this is fine, but sooner or later I start getting the following in the mongrel.log: Thread # is too old, killing. Wed Sep 13 00:34:42 CEST 2006: Error calling Dispatcher.dispatch #) not locked.> /usr/local/lib/ruby/1.8/sync.rb:57:in `Fail' /usr/local/lib/ruby/1.8/sync.rb:63:in `Fail' /usr/local/lib/ruby/1.8/sync.rb:183:in `sync_unlock' /usr/local/lib/ruby/1.8/sync.rb:231:in `synchronize' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/rails.rb:83:in `process' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:580:in `process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:579:in `process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:673:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:267:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:266:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:127:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/command.rb:203:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:231 /usr/local/bin/mongrel_rails:18 Often I get many, many of these in succession. Usually mongrel will stop responding shortly after these start showing up, but not always. Now when Mongrel dies it sometimes uses up all of the CPU time it can get it's hands on. I tried to get a backtrace from gdb by attaching to the running process and asking nicely for a backtrace, here's what gdb tells me (not sure if it really tells that much): #0 0x2823e9fb in nanosleep () from /lib/libc.so.6 #1 0x281823fe in _nanosleep () from /usr/lib/libpthread.so.2 #2 0x28182602 in nanosleep () from /usr/lib/libpthread.so.2 #3 0x281790eb in select () from /usr/lib/libpthread.so.2 #4 0x280ad34c in rb_thread_wait_for () from /usr/local/lib/libruby18.so.18 #5 0x280e4dec in rb_f_sleep () from /usr/local/lib/libruby18.so.18 #6 0x280a40ac in rb_call0 () from /usr/local/lib/libruby18.so.18 #7 0x280a4c5d in rb_call () from /usr/local/lib/libruby18.so.18 #8 0x2809f369 in rb_eval () from /usr/local/lib/libruby18.so.18 #9 0x280a2444 in rb_yield_0 () from /usr/local/lib/libruby18.so.18 #10 0x280a285e in rb_f_loop () from /usr/local/lib/libruby18.so.18 #11 0x280a40be in rb_call0 () from /usr/local/lib/libruby18.so.18 #12 0x280a4c5d in rb_call () from /usr/local/lib/libruby18.so.18 #13 0x2809f369 in rb_eval () from /usr/local/lib/libruby18.so.18 #14 0x2809e275 in rb_eval () from /usr/local/lib/libruby18.so.18 #15 0x280a2444 in rb_yield_0 () from /usr/local/lib/libruby18.so.18 #16 0x280ae89f in rb_thread_yield () from /usr/local/lib/libruby18.so.18 #17 0x280ae5ed in rb_thread_start_0 () from /usr/local/lib/libruby18.so.18 #18 0x280ae9a7 in rb_thread_initialize () from /usr/local/lib/libruby18.so.18 #19 0x280a4098 in rb_call0 () from /usr/local/lib/libruby18.so.18 #20 0x280a4c5d in rb_call () from /usr/local/lib/libruby18.so.18 #21 0x280a507d in rb_funcall2 () from /usr/local/lib/libruby18.so.18 #22 0x280a785e in rb_obj_call_init () from /usr/local/lib/libruby18.so.18 #23 0x280ae8dc in rb_thread_s_new () from /usr/local/lib/libruby18.so.18 #24 0x280a40ac in rb_call0 () from /usr/local/lib/libruby18.so.18 #25 0x280a4c5d in rb_call () from /usr/local/lib/libruby18.so.18 #26 0x2809f11c in rb_eval () from /usr/local/lib/libruby18.so.18 #27 0x2809e275 in rb_eval () from /usr/local/lib/libruby18.so.18 #28 0x2809fe04 in rb_eval () from /usr/local/lib/libruby18.so.18 #29 0x280a480e in rb_call0 () from /usr/local/lib/libruby18.so.18 #30 0x280a4c5d in rb_call () from /usr/local/lib/libruby18.so.18 #31 0x2809f11c in rb_eval () from /usr/local/lib/libruby18.so.18 #32 0x280a480e in rb_call0 () from /usr/local/lib/libruby18.so.18 #33 0x280a4c5d in rb_call () from /usr/local/lib/libruby18.so.18 #34 0x2809f11c in rb_eval () from /usr/local/lib/libruby18.so.18 #35 0x280a480e in rb_call0 () from /usr/local/lib/libruby18.so.18 #36 0x280a4c5d in rb_call () from /usr/local/lib/libruby18.so.18 #37 0x2809f11c in rb_eval () from /usr/local/lib/libruby18.so.18 #38 0x2809daae in rb_eval () from /usr/local/lib/libruby18.so.18 #39 0x2809ac9d in eval_node () from /usr/local/lib/libruby18.so.18 #40 0x280a6588 in rb_load () from /usr/local/lib/libruby18.so.18 #41 0x280a6842 in rb_f_load () from /usr/local/lib/libruby18.so.18 #42 0x280a40ac in rb_call0 () from /usr/local/lib/libruby18.so.18 #43 0x280a4c5d in rb_call () from /usr/local/lib/libruby18.so.18 #44 0x2809f369 in rb_eval () from /usr/local/lib/libruby18.so.18 #45 0x2809ac9d in eval_node () from /usr/local/lib/libruby18.so.18 #46 0x2809b229 in ruby_exec_internal () from /usr/local/lib/libruby18.so.18 #47 0x2809b28d in ruby_exec () from /usr/local/lib/libruby18.so.18 #48 0x2809b2c1 in ruby_run () from /usr/local/lib/libruby18.so.18 #49 0x08048649 in main () This corresponds to what top tells me (nanslp). Additionally I tried reattaching to the process a couple of times with gdb, and each time the backtrace looked the same. I've been trying to dig through the Mongrel code but I haven't fully grasped what's going on with all the threads in there, so I hope someone more insightful might be able to solve these issues. A couple of further observations: The above seems to be replicating whether I run with numprocs set to 1 or to 1024. Also I'm a bit surprised that I can from time to time experience that there are one more processor than the max allowed, I assume this is due to the threading and most likely is not a problem. I would really like to get this issue resolved so I can get back to using Mongrel for production on FreeBSD and if necessary I am willing to spend some time trying to resolve these issues, but I will probably need some help if I am to succeed. So please let me know if I can provide any further information or give me a pointer to where to go from here. -- Cheers, - Jacob Atzen From zedshaw at zedshaw.com Wed Sep 13 18:24:25 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 13 Sep 2006 15:24:25 -0700 Subject: [Mongrel] Mongrel spewing backtraces and nanosleeping In-Reply-To: <20060913140021.GA1152@nezbo.dhcp.aub.dk> References: <20060913140021.GA1152@nezbo.dhcp.aub.dk> Message-ID: <1158186265.9628.10.camel@localhost.localdomain> On Wed, 2006-09-13 at 16:00 +0200, Jacob Atzen wrote: > Hi list, > > I'm seeing a couple of issues with Mongrel. I'm running FreeBSD 6.1 and > have previously been told that there are known conflicts between this > and Mongrel, yet I hope these issues will be resolved with time. > > I'm overloading Mongrel with httperf on my local workstation. Mongrel is > started directly with the mongrel_rails command and there is only one > mongrel running. Soon I will start seeing: > This guy walks into the doctors office and says, "Doc! It hurts when I do this." He then sticks his finger in his eye and gouges out his cornea and eats it. The doctor yells, "What the hell did you do that for?!" Guy says, "So I can test how much damage my eye can take. See, it sucks, I need a stronger eye." In other words, congratulations you've overloaded Mongrel with httperf. That's not too hard since Ruby only has 1024 files and you're probably hitting a rails action that opens loads and loads of files or just plain maxing it out. The way mongrel defends itself is to try closing things off, but there's not much it actually can do. It's at the mercy of Ruby and that's that. End of story. So, there's no "issue" other than you need: 1) To tune your rails actions to be faster. 2) More mongrel processes. 3) To not do this to mongrel. 4) Maybe more machines if this is the load you have to handle. You should also get the 0.3.13.4 pre-release and use the USR1 logging (mentioned on this list many times) to debug which rails action is taking the longest and holding up the other threads. Then tune that rails action up to service the requests faster. Hope that helps. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From jacob at jacobatzen.dk Thu Sep 14 05:27:01 2006 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Thu, 14 Sep 2006 11:27:01 +0200 Subject: [Mongrel] Mongrel spewing backtraces and nanosleeping In-Reply-To: <1158186265.9628.10.camel@localhost.localdomain> References: <20060913140021.GA1152@nezbo.dhcp.aub.dk> <1158186265.9628.10.camel@localhost.localdomain> Message-ID: <20060914092701.GA1382@nezbo.dhcp.aub.dk> On Wed, Sep 13, 2006 at 03:24:25PM -0700, Zed Shaw wrote: > On Wed, 2006-09-13 at 16:00 +0200, Jacob Atzen wrote: > > Hi list, > > > > I'm seeing a couple of issues with Mongrel. I'm running FreeBSD 6.1 and > > have previously been told that there are known conflicts between this > > and Mongrel, yet I hope these issues will be resolved with time. > > > > I'm overloading Mongrel with httperf on my local workstation. Mongrel is > > started directly with the mongrel_rails command and there is only one > > mongrel running. Soon I will start seeing: > > > > This guy walks into the doctors office and says, "Doc! It hurts when I > do this." He then sticks his finger in his eye and gouges out his > cornea and eats it. The doctor yells, "What the hell did you do that > for?!" Guy says, "So I can test how much damage my eye can take. See, > it sucks, I need a stronger eye." I will try to explain my motivation for the tests performed. I was seeing Mongrel processes freezing in the sense that they stopped handling incoming requests on a production system. As part of the debugging of this I tried to create a setup where I minimized the external factors (Apache, Rails to a certain extent) and putting load on this to see if I could reproduce this behaviour. Now if anyone has suggestions on better ways of doing this I'm all ears. > In other words, congratulations you've overloaded Mongrel with httperf. > That's not too hard since Ruby only has 1024 files and you're probably > hitting a rails action that opens loads and loads of files or just plain > maxing it out. I'm seeing the same behaviour with 256 threads and lsof shows a stable amount of files opened by Ruby (around 290) throughout the running of the test. Additionally sockstat shows 255 sockets opened by Ruby throughout. My rails action is trivial, this is the implementation: def test render :text => "Just testing" end > The way mongrel defends itself is to try closing things off, but there's > not much it actually can do. It's at the mercy of Ruby and that's that. > End of story. > > So, there's no "issue" other than you need: > > 1) To tune your rails actions to be faster. > 2) More mongrel processes. > 3) To not do this to mongrel. > 4) Maybe more machines if this is the load you have to handle. > > You should also get the 0.3.13.4 pre-release and use the USR1 logging > (mentioned on this list many times) to debug which rails action is > taking the longest and holding up the other threads. Then tune that > rails action up to service the requests faster. > > Hope that helps. Of course I should have mentioned the following in my previous post, I'm sorry for the omission: - I am running the 0.3.13.4 pre-release fetched this tuesday. - The Rails action is minimized as shown above. - I am using USR1 debugging and seeing output resembling: Wed Sep 13 00:34:36 CEST 2006: 156 threads sync_waiting for /pages/test, 1000 still active in mongrel. Now Rails is telling me it can complete 1000+ requests a second, so I interpret this number as it's Ruby/Mongrel/Whatever that's using the majority of the time processing the requests. Of course my interpretation may be wrong. I'm not really concerned about performance. The problem is that Mongrel from time to time will end up in what appears to be an endless loop where it stops responding to anything besides a kill -9. I've noticed that both the open socket count and the open file count stays constant when this happens, which to me is a further indication that something is stuck somewhere. Finally the problem occurs after very different amounts of requests, sometimes it will show after only 30-40000 hits from httperf, sometimes I can get 10 times that. I will not start guessing as to why this is. I don't mind Mongrel trying to defend itself and closing things off. And if there's something inherent in Ruby or whatever which means that if Mongrel gets loaded it may suddenly stop responding I will just go back to mod_fcgid. In conclusion I believe there is an issue, namely that Mongrel from time to time freezes totally and never recovers. I hope the above explanation clarifies my position. If you do not think this is an issue that's fine and I will not pursue the matter further. -- Sincerely, - Jacob Atzen From wyhaines at gmail.com Thu Sep 14 10:07:38 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Thu, 14 Sep 2006 08:07:38 -0600 Subject: [Mongrel] Mongrel spewing backtraces and nanosleeping In-Reply-To: <20060914092701.GA1382@nezbo.dhcp.aub.dk> References: <20060913140021.GA1152@nezbo.dhcp.aub.dk> <1158186265.9628.10.camel@localhost.localdomain> <20060914092701.GA1382@nezbo.dhcp.aub.dk> Message-ID: I am wondering if this might arise because of a potential race condition within Sync? A 'Thread.critical = true' does not affect threads that did not exist at the time that it was called, and the lock() in Sync does quite a bit of work between when it declares a critical area and when a thread either gets the lock or does not. If a bunch of threads are killed very quickly, one of the remaining threads will get into that thread critical section, but I think it may be possible for a newly spawned thread to also get into there before the other one finishes its work. If that happens, and two threads think they have the lock, while Sync thinks only one does, then when the one that does not have the lock calls unlock, you get the error that you reported. Jacob, I have attached a version of thread.rb that makes a slight change to Mutex to avoid the memory management issues that the stock one runs into with regard to Array. It is otherwise identical to the stock thread.rb. I am curious if you replace your thread.rb with this one, and flip Mongrel back to using Mutex, if you can still get this same failure mode to happen? Kirk Haines -------------- next part -------------- A non-text attachment was scrubbed... Name: thread.rb Type: application/x-ruby Size: 8406 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060914/1195f96a/attachment.bin From jacob at jacobatzen.dk Thu Sep 14 11:27:52 2006 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Thu, 14 Sep 2006 17:27:52 +0200 Subject: [Mongrel] Mongrel spewing backtraces and nanosleeping In-Reply-To: References: <20060913140021.GA1152@nezbo.dhcp.aub.dk> <1158186265.9628.10.camel@localhost.localdomain> <20060914092701.GA1382@nezbo.dhcp.aub.dk> Message-ID: <20060914152752.GA20862@nezbo.dhcp.aub.dk> On Thu, Sep 14, 2006 at 08:07:38AM -0600, Kirk Haines wrote: > I am wondering if this might arise because of a potential race > condition within Sync? A 'Thread.critical = true' does not affect > threads that did not exist at the time that it was called, and the > lock() in Sync does quite a bit of work between when it declares a > critical area and when a thread either gets the lock or does not. > > If a bunch of threads are killed very quickly, one of the remaining > threads will get into that thread critical section, but I think it may > be possible for a newly spawned thread to also get into there before > the other one finishes its work. > > If that happens, and two threads think they have the lock, while Sync > thinks only one does, then when the one that does not have the lock > calls unlock, you get the error that you reported. > > Jacob, I have attached a version of thread.rb that makes a slight > change to Mutex to avoid the memory management issues that the stock > one runs into with regard to Array. It is otherwise identical to the > stock thread.rb. I am curious if you replace your thread.rb with this > one, and flip Mongrel back to using Mutex, if you can still get this > same failure mode to happen? How do I get Mongrel to use Mutex? -- Cheers, - Jacob Atzen From wyhaines at gmail.com Thu Sep 14 12:04:56 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Thu, 14 Sep 2006 10:04:56 -0600 Subject: [Mongrel] Mongrel spewing backtraces and nanosleeping In-Reply-To: <20060914152752.GA20862@nezbo.dhcp.aub.dk> References: <20060913140021.GA1152@nezbo.dhcp.aub.dk> <1158186265.9628.10.camel@localhost.localdomain> <20060914092701.GA1382@nezbo.dhcp.aub.dk> <20060914152752.GA20862@nezbo.dhcp.aub.dk> Message-ID: On 9/14/06, Jacob Atzen wrote: > How do I get Mongrel to use Mutex? In your mongrel/rails.rb, right at the beginning: require 'sync' Comment that out and add require 'thread' Use the thread lib I sent to you, as it should fix the problem that caused Zed to want to switch from Mutex to Sync in the first place. Then, just below that, in this code: class RailsHandler < Mongrel::HttpHandler attr_reader :files attr_reader :guard @@file_only_methods = ["GET","HEAD"] def initialize(dir, mime_map = {}) @files = Mongrel::DirHandler.new(dir,false) @guard = Sync.new That last line, comment it out and add: @guard = Mutex.new Then try your test again and see if you can reproduce that mode of failure. Kirk Haines From java at kannan.us Thu Sep 14 12:16:29 2006 From: java at kannan.us (=?iso-8859-1?Q?java?=) Date: Thu, 14 Sep 2006 16:16:29 +0000 Subject: [Mongrel] How do I connect to mongrel that's behind a router from outside world Message-ID: <20060914161629.15934.qmail@hosting334.com> Hello, I am new to mongrel. I have mongrel running on a linux machine (Fedora core), which sits behind a broadband router. The linux machine has the typical 192.168... internal IP address. We use the dynamicdns to connect to the linux machine from outside world. Now, my question is how can myself and my colleagues connect to mongrel from outside world. I tried starting mongrel with the -a (-address) option by specifying (0.0.0.0 default), its internal ip (192.168..), the public IP address, the dynamic dns name. None of these worked. So my question is: 1. Do I need apache to route these calls to mongrel (by using mod_proxy) ? 2. Do I leave the default address (0.0.0.0) for mongrel on the linux box ? 3. Is mongrel a HTTP server like apache ? Any help would be appreciated. Thanks, Kannan From zedshaw at zedshaw.com Thu Sep 14 18:53:49 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 14 Sep 2006 15:53:49 -0700 Subject: [Mongrel] How do I connect to mongrel that's behind a router from outside world In-Reply-To: <20060914161629.15934.qmail@hosting334.com> References: <20060914161629.15934.qmail@hosting334.com> Message-ID: <1158274429.6032.24.camel@localhost.localdomain> On Thu, 2006-09-14 at 16:16 +0000, java wrote: > Hello, > > I am new to mongrel. I have mongrel running on a linux machine (Fedora core), which sits behind a broadband router. The linux machine has the typical 192.168... internal IP address. We use the dynamicdns to connect to the linux machine from outside world. > > Now, my question is how can myself and my colleagues connect to mongrel from outside world. You have to tell your router to forward connections to the *router's* port 80 to your computer inside the firewall. Please read your router's manual and online instructions for how to do this. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From eimorton at gmail.com Thu Sep 14 20:52:12 2006 From: eimorton at gmail.com (Erik Morton) Date: Thu, 14 Sep 2006 20:52:12 -0400 Subject: [Mongrel] Caching::Sweeper Access to Controller Message-ID: <50C37787-1333-4D63-8C41-8E0FBB227EEF@gmail.com> Hello, I'm running Mongrel 0.3.13.3, cluster 0.2.0, and Rails 1.1.6 and I have a problem with a sweeper not having access to the controller instance. NoMethodError (undefined method `session' for nil:NilClass): /app/models/audit_sweeper.rb:16:in `log' /app/models/audit_sweeper.rb:9:in `after_update' /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ active_record/observer.rb:123:in `send' /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ active_record/observer.rb:123:in `update' /usr/lib/ruby/1.8/observer.rb:185:in `notify_observers' /usr/lib/ruby/1.8/observer.rb:184:in `each' /usr/lib/ruby/1.8/observer.rb:184:in `notify_observers' Here's my code (the problem is with 'controller' being nil): def log(record, event, user = controller.session[:user]) a = AuditTrail.new(:record_id => record.id, :record_type => record.type.name, :event => event, :user_id => user) a.record_version = record.version if record.respond_to?("version") a.save! end The interesting thing is that it only happens on actions within one of the controllers that are calling the cache sweeper (cache_sweeper :audit_sweeper). Any help or pointers would be much appreciated. Erik From technoweenie at gmail.com Thu Sep 14 21:26:58 2006 From: technoweenie at gmail.com (Rick Olson) Date: Thu, 14 Sep 2006 20:26:58 -0500 Subject: [Mongrel] Caching::Sweeper Access to Controller In-Reply-To: <50C37787-1333-4D63-8C41-8E0FBB227EEF@gmail.com> References: <50C37787-1333-4D63-8C41-8E0FBB227EEF@gmail.com> Message-ID: <48fe25b0609141826k63672edclb5c2df5f33f9d9ad@mail.gmail.com> On 9/14/06, Erik Morton wrote: > Hello, > I'm running Mongrel 0.3.13.3, cluster 0.2.0, and Rails 1.1.6 and I > have a problem with a sweeper not having access to the controller > instance. > > NoMethodError (undefined method `session' for nil:NilClass): > /app/models/audit_sweeper.rb:16:in `log' > /app/models/audit_sweeper.rb:9:in `after_update' > /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ > active_record/observer.rb:123:in `send' > /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ > active_record/observer.rb:123:in `update' > /usr/lib/ruby/1.8/observer.rb:185:in `notify_observers' > /usr/lib/ruby/1.8/observer.rb:184:in `each' > /usr/lib/ruby/1.8/observer.rb:184:in `notify_observers' > > Here's my code (the problem is with 'controller' being nil): > def log(record, event, user = controller.session[:user]) > a = AuditTrail.new(:record_id => record.id, :record_type => > record.type.name, > :event => event, :user_id => user) > a.record_version = record.version if record.respond_to?("version") > a.save! > end > > The interesting thing is that it only happens on actions within one > of the controllers that are calling the cache sweeper > (cache_sweeper :audit_sweeper). > > Any help or pointers would be much appreciated. > > Erik This is an issue with your rails app, not mongrel. You probably need to specify which actions the cache sweeper is supposed to run on: cache_sweeper :audit_sweeper, :only => [:create, :update, :destroy] That method will set up an around filter using the Cache Sweeper class that sets the controller instance var. This brings up some possible issues, because the Cache Sweeper is still an Observer. Once it's instantiated, it's going to fire the callbacks on any model it's observing, even if it's not being saved on a controller it was configured for. So, it's best to put a 'return if controller.nil?' at the top of the cache sweepers, or just be ready to solve these issues if they come up. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com From jgeiger at gmail.com Thu Sep 14 21:30:23 2006 From: jgeiger at gmail.com (Joey Geiger) Date: Thu, 14 Sep 2006 20:30:23 -0500 Subject: [Mongrel] Caching::Sweeper Access to Controller In-Reply-To: <50C37787-1333-4D63-8C41-8E0FBB227EEF@gmail.com> References: <50C37787-1333-4D63-8C41-8E0FBB227EEF@gmail.com> Message-ID: <466af3440609141830k65e2547en80d28b1ccce0eb72@mail.gmail.com> I'm actually doing similar code, and it's working for me with the same setup. I do have the issue with trying to figure out how to test that sweeper code though... On 9/14/06, Erik Morton wrote: > Hello, > I'm running Mongrel 0.3.13.3, cluster 0.2.0, and Rails 1.1.6 and I > have a problem with a sweeper not having access to the controller > instance. > > NoMethodError (undefined method `session' for nil:NilClass): > /app/models/audit_sweeper.rb:16:in `log' > /app/models/audit_sweeper.rb:9:in `after_update' > /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ > active_record/observer.rb:123:in `send' > /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ > active_record/observer.rb:123:in `update' > /usr/lib/ruby/1.8/observer.rb:185:in `notify_observers' > /usr/lib/ruby/1.8/observer.rb:184:in `each' > /usr/lib/ruby/1.8/observer.rb:184:in `notify_observers' > > Here's my code (the problem is with 'controller' being nil): > def log(record, event, user = controller.session[:user]) > a = AuditTrail.new(:record_id => record.id, :record_type => > record.type.name, > :event => event, :user_id => user) > a.record_version = record.version if record.respond_to?("version") > a.save! > end > > The interesting thing is that it only happens on actions within one > of the controllers that are calling the cache sweeper > (cache_sweeper :audit_sweeper). > > Any help or pointers would be much appreciated. > > Erik > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From jacob at jacobatzen.dk Fri Sep 15 09:02:11 2006 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Fri, 15 Sep 2006 15:02:11 +0200 Subject: [Mongrel] Mongrel spewing backtraces and nanosleeping In-Reply-To: References: <20060913140021.GA1152@nezbo.dhcp.aub.dk> <1158186265.9628.10.camel@localhost.localdomain> <20060914092701.GA1382@nezbo.dhcp.aub.dk> <20060914152752.GA20862@nezbo.dhcp.aub.dk> Message-ID: <20060915130211.GA14836@nezbo.dhcp.aub.dk> On Thu, Sep 14, 2006 at 10:04:56AM -0600, Kirk Haines wrote: > On 9/14/06, Jacob Atzen wrote: > > > How do I get Mongrel to use Mutex? > > In your mongrel/rails.rb, right at the beginning: > > require 'sync' > > Comment that out and add > > require 'thread' > > Use the thread lib I sent to you, as it should fix the problem that > caused Zed to want to switch from Mutex to Sync in the first place. > > Then, just below that, in this code: > > class RailsHandler < Mongrel::HttpHandler > attr_reader :files > attr_reader :guard > @@file_only_methods = ["GET","HEAD"] > > def initialize(dir, mime_map = {}) > @files = Mongrel::DirHandler.new(dir,false) > @guard = Sync.new > > That last line, comment it out and add: > > @guard = Mutex.new > > Then try your test again and see if you can reproduce that mode of failure. A little heads-up before the weekend, I've been running with the above modifications and a few more to make the mutex calls run. So far I've been processing ~28000 rails requests on a mongrel with a limit of 64 processors. I will perform further testing and supply a full diff of my modifications early next week. -- Cheers, - Jacob Atzen From lists at lastonepicked.com Fri Sep 15 14:33:26 2006 From: lists at lastonepicked.com (HH) Date: Fri, 15 Sep 2006 11:33:26 -0700 Subject: [Mongrel] Running Shell Scripts/Commands at Startup? Message-ID: Someone on the Rails list mentioned that they thought it was possible to get Mongrel to launch other processes at start time. I have an app that relies on backgroundrb and also an external listening program and I'd love it if I could set it up so that when Mongrel starts, these start as well. Is it true that this can be done? Where would I look for documentation on this? I thought perhaps the -S option might help but it looks like that's for something else. Thanks, H From gethemant at gmail.com Fri Sep 15 15:00:32 2006 From: gethemant at gmail.com (hemant) Date: Sat, 16 Sep 2006 00:30:32 +0530 Subject: [Mongrel] Running Shell Scripts/Commands at Startup? In-Reply-To: References: Message-ID: On 9/16/06, HH wrote: > > Someone on the Rails list mentioned that they thought it was possible to > get > Mongrel to launch other processes at start time. > > I have an app that relies on backgroundrb and also an external listening > program and I'd love it if I could set it up so that when Mongrel starts, > these start as well. > > Is it true that this can be done? > > Where would I look for documentation on this? > > I thought perhaps the -S option might help but it looks like that's for > something else. I think that "someone" was me. According to Zed : You could put it in a mongrel.conf and just have Mongrel run it on > start-up: > > mongrel_rails start -S mongrel.conf > > (Even though it ends in .conf it's actually Ruby code that gets run > inside the Configurator.) > > I am not entirely sure, what Zed meant by inside Configurator, but you can always write a ruby program, which will fork the process and detach itself from the current process using Process.detach. So, technically this script should work: exec("rake backgroundrb:start") if fork.nil? Process.detach Of course...i haven't tested it and you need to set some environment stuff...before you can have access to proper rake command. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060916/907aa08d/attachment.html From gethemant at gmail.com Fri Sep 15 15:04:59 2006 From: gethemant at gmail.com (hemant) Date: Sat, 16 Sep 2006 00:34:59 +0530 Subject: [Mongrel] Running Shell Scripts/Commands at Startup? In-Reply-To: References: Message-ID: So, technically this script should work: > > exec("rake backgroundrb:start") if fork.nil? > Process.detach > > Of course...i haven't tested it and you need to set some environment > stuff...before you can have access to proper rake command. > > between Ezra has already cranked out that script...so wait for his next shiny release of backgroundrb plugin. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060916/182c6eea/attachment.html From joeat303 at yahoo.com Sat Sep 16 13:28:28 2006 From: joeat303 at yahoo.com (Joe Ruby) Date: Sat, 16 Sep 2006 10:28:28 -0700 (PDT) Subject: [Mongrel] Mongrel and Sandbox Message-ID: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> Z-Man, DHH recently said: "And [_why's] latest work on sandbox looks stellar. Making it drop-dead easy to run multiple Rails applications in the same Mongrel process without conflicts. Thumbs up to both him and Matz for getting Sandbox on track for inclusion with the next Ruby release." Does that mean what I think it means - that one or more Mongrel processes may one day be able to serve multiple Rails apps? Or something wacky like that? Thanks, Joe Ruby MUDCRAP-CE __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jdz99 at hotmail.com Sat Sep 16 13:44:47 2006 From: jdz99 at hotmail.com (Jim Douglas) Date: Sat, 16 Sep 2006 17:44:47 +0000 Subject: [Mongrel] Mongrel and Sandbox In-Reply-To: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> Message-ID: >From: Joe Ruby >Reply-To: mongrel-users at rubyforge.org >To: mongrel-users at rubyforge.org >Subject: [Mongrel] Mongrel and Sandbox >Date: Sat, 16 Sep 2006 10:28:28 -0700 (PDT) > >Z-Man, > >DHH recently said: > >"And [_why's] latest work on sandbox looks stellar. >Making it drop-dead easy to run multiple Rails >applications in the same Mongrel process without >conflicts. Thumbs up to both him and Matz for getting >Sandbox on track for inclusion with the next Ruby >release." > >Does that mean what I think it means - that one or >more Mongrel processes may one day be able to serve >multiple Rails apps? Or something wacky like that? > >Thanks, >Joe Ruby >MUDCRAP-CE > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com >_______________________________________________ >Mongrel-users mailing list >Mongrel-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/mongrel-users I upgraded my box from FC4 to FC5, now when I visit the url for my app I get , Application error (Rails) This is the production log file, Errno::ENOENT (No such file or directory - /tmp/mysql.sock): /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/vendor/mysql.rb:104:in `initialize' MySQL is up and running, everything was fine on FC4... This is my database.yml production: adapter: mysql database: sales username: myuser password: mypw host: localhost Jim From technoweenie at gmail.com Sat Sep 16 14:16:51 2006 From: technoweenie at gmail.com (Rick Olson) Date: Sat, 16 Sep 2006 13:16:51 -0500 Subject: [Mongrel] Mongrel and Sandbox In-Reply-To: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> References: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> Message-ID: <48fe25b0609161116x3feaadb7nd99e759fec3ff5d9@mail.gmail.com> On 9/16/06, Joe Ruby wrote: > Z-Man, > > DHH recently said: > > "And [_why's] latest work on sandbox looks stellar. > Making it drop-dead easy to run multiple Rails > applications in the same Mongrel process without > conflicts. Thumbs up to both him and Matz for getting > Sandbox on track for inclusion with the next Ruby > release." > > Does that mean what I think it means - that one or > more Mongrel processes may one day be able to serve > multiple Rails apps? Or something wacky like that? > > Thanks, > Joe Ruby > MUDCRAP-CE That's the idea, I think. Not sure if it's actually working yet though. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com From dave.verwer at shinydevelopment.com Sat Sep 16 15:06:37 2006 From: dave.verwer at shinydevelopment.com (Dave Verwer) Date: Sat, 16 Sep 2006 20:06:37 +0100 Subject: [Mongrel] Mongrel and Sandbox In-Reply-To: <48fe25b0609161116x3feaadb7nd99e759fec3ff5d9@mail.gmail.com> References: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> <48fe25b0609161116x3feaadb7nd99e759fec3ff5d9@mail.gmail.com> Message-ID: He did a very brief demo of it at RailsConf Europe yesterday, unfortunately the projector broke just as he was launching up mongrel but apparently it is basically working. He was running beast and something else in the same mongrel process... just awesome and I cant wait for it. On 9/16/06, Rick Olson wrote: > On 9/16/06, Joe Ruby wrote: > > Z-Man, > > > > DHH recently said: > > > > "And [_why's] latest work on sandbox looks stellar. > > Making it drop-dead easy to run multiple Rails > > applications in the same Mongrel process without > > conflicts. Thumbs up to both him and Matz for getting > > Sandbox on track for inclusion with the next Ruby > > release." > > > > Does that mean what I think it means - that one or > > more Mongrel processes may one day be able to serve > > multiple Rails apps? Or something wacky like that? > > > > Thanks, > > Joe Ruby > > MUDCRAP-CE > > That's the idea, I think. Not sure if it's actually working yet though. > > > -- > Rick Olson > http://weblog.techno-weenie.net > http://mephistoblog.com > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From zedshaw at zedshaw.com Sat Sep 16 18:19:38 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Sat, 16 Sep 2006 15:19:38 -0700 Subject: [Mongrel] Mongrel and Sandbox In-Reply-To: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> References: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> Message-ID: <1158445178.8624.7.camel@localhost.localdomain> On Sat, 2006-09-16 at 10:28 -0700, Joe Ruby wrote: > Z-Man, > > DHH recently said: > > "And [_why's] latest work on sandbox looks stellar. > Making it drop-dead easy to run multiple Rails > applications in the same Mongrel process without > conflicts. Thumbs up to both him and Matz for getting > Sandbox on track for inclusion with the next Ruby > release." > Oh I didn't know he'd gotten it that together. Nice. Now if Matz could just be bothered to fix those memory leaks and help get rid of the 1024 file limit I think I'd be one happy fellow. :-) > Does that mean what I think it means - that one or > more Mongrel processes may one day be able to serve > multiple Rails apps? Or something wacky like that? > Yep, well for _why it's at least to run multiple separated camping apps, but Rails is the holy grail for sure. Not sure how incredibly smart and/or stupid this will be but man it'd sure make a few people's day. > Thanks, > Joe Ruby > MUDCRAP-CE ^^^^^^ Hey, I don't remember you at the last course... -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From technoweenie at gmail.com Sat Sep 16 18:28:23 2006 From: technoweenie at gmail.com (Rick Olson) Date: Sat, 16 Sep 2006 17:28:23 -0500 Subject: [Mongrel] Mongrel and Sandbox In-Reply-To: <1158445178.8624.7.camel@localhost.localdomain> References: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> <1158445178.8624.7.camel@localhost.localdomain> Message-ID: <48fe25b0609161528n238d4ac2rbd7d2e57556fbaea@mail.gmail.com> > > MUDCRAP-CE > ^^^^^^ > Hey, I don't remember you at the last course... Are there already mail-order MUDCRAP certs? -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com From wyhaines at gmail.com Sat Sep 16 20:33:53 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Sat, 16 Sep 2006 18:33:53 -0600 Subject: [Mongrel] Mongrel and Sandbox In-Reply-To: <1158445178.8624.7.camel@localhost.localdomain> References: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> <1158445178.8624.7.camel@localhost.localdomain> Message-ID: On 9/16/06, Zed Shaw wrote: > Now if Matz could just be bothered to fix those memory leaks and help > get rid of the 1024 file limit I think I'd be one happy fellow. :-) He asked that the patch for the Hash related leak that I found be committed, so I think that one is taken care of. For the issue with Mutex, I should bring it up on ruby-core, because I don't know if the behavior or Array, to not realloc on a shift, is intentional or not, so I don't know whether to contribute a patch to that or to just offer a patch to Mutex to make it use unshift and pop instead of shift and push. Kirk From andrew at sophrinix.com Sun Sep 17 01:40:38 2006 From: andrew at sophrinix.com (=?iso-8859-1?Q?andrew?=) Date: Sat, 16 Sep 2006 23:40:38 -0600 Subject: [Mongrel] Mongrel and Sandbox Message-ID: <20060917054038.23982.qmail@server285.com> > -------Original Message------- > From: Rick Olson > Subject: Re: [Mongrel] Mongrel and Sandbox > Sent: Sep 16 '06 16:28 > > > > MUDCRAP-CE > > ^^^^^^ > > Hey, I don't remember you at the last course... > > Are there already mail-order MUDCRAP certs? > > -- > Rick Olson > http://weblog.techno-weenie.net > http://mephistoblog.com I was not let in on the mudcrap-ce certs mailorder... so the final exam for the mudcrap-ce exam does include having the best house coat out of the entire class, right? :-P Andrew mudcrap-ce --enable super-cow-powers From joeat303 at yahoo.com Sun Sep 17 02:27:52 2006 From: joeat303 at yahoo.com (Joe Ruby) Date: Sat, 16 Sep 2006 23:27:52 -0700 (PDT) Subject: [Mongrel] Mongrel and Sandbox Message-ID: <20060917062752.72597.qmail@web38607.mail.mud.yahoo.com> > Now if Matz could just be bothered to fix those memory leaks and help > get rid of the 1024 file limit I think I'd be one happy fellow. :-) Hopefully he's aware. > > Thanks, > > Joe Ruby > > MUDCRAP-CE > ^^^^^^ > Hey, I don't remember you at the last course... I was able to finagle me an advance copy of "MUDCRAP-CE in 24 Hours for the Complete Moron." ;P > Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu Joe Ruby MUDCRAP-CE CRUD Pro DHH Owes Me Shit __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From al-mongrelusers at none.at Sun Sep 17 11:51:26 2006 From: al-mongrelusers at none.at (Alexander Lazic) Date: Sun, 17 Sep 2006 17:51:26 +0200 Subject: [Mongrel] [OT] Jfyi Nginx wiki Message-ID: <20060917155126.GA19944@none.at> Hi, due the fact that some peoples on the list looks interested to nginx i will tell you that there is a wiki out there: http://wiki.codemongers.com/ Regards Alex From david at amazing.com Sun Sep 17 19:22:37 2006 From: david at amazing.com (David Dennis) Date: Sun, 17 Sep 2006 19:22:37 -0400 Subject: [Mongrel] Question about mongrel_upload_progress Message-ID: <28F0A5AE-CB64-4B39-BFA4-7EAACE3A7136@amazing.com> Like most people, I find the file upload process very annoying, in that you hit submit and sit there, seemingly forever, as your file gets sent. So I felt it would be a great goodness to have progress updates as file_upload_progress offers. However, I have been unable to get it to work, and I'm not sure why. I created the form roughly as said, except that my target is creations/create instead of the one in the documentation. I changed the file_path in the configuration file to creations/create, and sure enough, the form started spitting out requests for 'files/progress', providing lots of not found errors but also apparently inspiring a response from the server. However, the client never updated progress from 0%. I took a look at the server and put some diagnostics in and was able to determine that the server was properly intercepting the request and coming up with a steadily decreasing number, which looked suspiciously like the remaining number of bytes left to upload. Here's the routine I changed: private def upload_notify(action, params, *args) system("echo path info comparison worked! >>/tmp/test") upload_id = Mongrel::HttpRequest.query_parse(params ['QUERY_STRING'])['upload_id'] system("echo Upload id #{ upload_id } found >>/tmp/test") if params[Mongrel::Const::REQUEST_METHOD] == 'POST' && upload_id system("echo a response was returned action #{ action } args # { args } >>/tmp/test"\ ) Mongrel::Uploads.instance.send(action, upload_id, *args) if upload_id end end Here are the last few lines of the output: a response was returned action mark args 24576 path info comparison worked! Upload id 1158534572 found a response was returned action mark args 20480 path info comparison worked! Upload id 1158534572 found a response was returned action mark args 16384 path info comparison worked! Upload id 1158534572 found path info being compared /files/progress a response was returned action mark args 12288 path info comparison worked! Upload id 1158534572 found a response was returned action mark args 8192 path info comparison worked! Upload id 1158534572 found a response was returned action mark args 4096 path info comparison worked! Upload id 1158534572 found a response was returned action mark args 0 path info comparison worked! Upload id 1158534572 found So it looks like it is successfully tracking the upload of the file. But how is it being sent back to the client? The /files/progress calls appear to be correctly running this routine but then continuing to move forward in the rails system to cause the no route error. I have about a million of these in the development log: Processing Base#index (for 127.0.0.1 at 2006-09-17 19:16:59) [POST] Session ID: 126d2f8aeac54478f881174bae52c844 Parameters: {"upload_id"=>"1158534572"} ActionController::RoutingError (Recognition failed for "/files/ progress"): /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/ action_controller/routing.rb:526:in `recognition_failed' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/ action_controller/routing.rb:516:in `recognize!' So why would the routine correctly calculate the progress and then continue through to error out? I looked at the JavaScript and this also confuses me since I see the call to a new Ajax object, which works to send the request, but not how the request is linked to the processing code. And indeed when I added alert() to the processing code, I never saw anything happen: update: function(total, current) { alert("We actually are updating! Total " + total + " / " + current); if(!this.uploading) return; var status = current / total; var statusHTML = status.toPercentage(); $('results').innerHTML = statusHTML + "
" + current.toHumanSize() + ' of ' + total.toHumanSize() + " uploaded."; this.StatusBar.update(status, statusHTML); }, I didn't get any JavaScript errors so I have to assume that it is not trying to update when it returns. I would expect error messages if it was receiving the errors from the server. I'm at my wit's end on this one, largely because of huge gaps in my knowledge of how JavaScript and Mongrel work. Can someone give me a pointer or two towards a resolution? Many thanks for any help you can give. D From zedshaw at zedshaw.com Mon Sep 18 05:26:41 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 18 Sep 2006 02:26:41 -0700 Subject: [Mongrel] [ANN] Finally! Mongrel 0.3.13.4 Official (for Unix) Message-ID: <1158571601.8230.21.camel@localhost.localdomain> Hello! Today I'm announcing a "soft but official" release of Mongrel 0.3.13.4 for the Unix fans in the crowd. It's been running stable for quite some time now for many people, and should be great for nearly everyone. You can read the announce at: http://mongrel.rubyforge.org/ This release includes new versions of mongrel_upload_progress and mongrel_cluster. INSTALLING As usual you install it using: gem install mongrel And I'm really really sorry about the forty thousand gems that get listed. I promise to drive one of the RubyGems guys into a corner until they help me clean that mess out. *Win32* people will be able to upgrade in the next week or so. CHANGES Coming soon... it's lots of stuff. WIN32 LAG In the past I've held up Mongrel releases in order to get win32 working well, but now we'll do a separate release when win32 is done and most likely give it a slightly different version number like the mysql folks do. This should let us get releases out to both parties as they're stable. BTW, all you folks who really like Mongrel on win32 might want to consider pitching in and at least learning how to build the gem and test it. That way when a Unix release comes out you can give us feedback and possibly help with the release engineering. Contact me off-list if you're interested. NEXT STEPS I've been experimenting with lots of weird little ideas and going through various potential moves for the future of Mongrel. Let me know what you'd like in Mongrel. Some of my top hit list items are: * A "mostly C" version for Unix only that's fast as blazes. * Getting rid of mongrel_cluster and working on a complete unified system that properly manages a set of Ruby interpreters. Contemplating working this out so that win32 also gets a similar setup. * Is anyone else tired of 10_000 ways to deploy Mongrel? Maybe work on developing "the one true way" with all the others being a optional setups, and working on making this TOTW damn easy. * Nginx module? Why nginx? Because I can read nginx code. Sad that I can read a Russian's code better than the Apache code and that his configuration file format is way better. * Get with the ServerSide fellow and talk about a merger since that thing is damn fast. * Certificates for all the newly minted MUDCRAP-CE graduates! What else would people like to see worked on, and what are you all willing to help with? -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From neil at aldur.co.uk Mon Sep 18 06:43:38 2006 From: neil at aldur.co.uk (Neil Wilson) Date: Mon, 18 Sep 2006 11:43:38 +0100 Subject: [Mongrel] [ANN] Finally! Mongrel 0.3.13.4 Official (for Unix) In-Reply-To: <1158571601.8230.21.camel@localhost.localdomain> References: <1158571601.8230.21.camel@localhost.localdomain> Message-ID: Thanks for your effort on this Zed. I certainly appreciate what you are doing and the effort you put into Mongrel. Is it time to step back and consider what Mongrel is about? Is it the wrapper around Rails (in which case couldn't it be a lot simpler. Automatic cluster and eliminate the thread code so that Mongrel simply refuses connections if the dispatcher is operational)? Or do you intend that it should be more than that? I think Mongrel feels more complex than it used to do. I'd certainly like to see a degree of abstraction coming in that hides the complexity for the majority case - which I still hope is launching Rails apps in a Ruby driven application server probably as a cluster of separate processes and front-ended by one of the web servers - Apache for want of a lighter alternative that works. You can buy raw execution speed - that's relatively cheap. What the web and application systems need to take away, IMHO, are the problems of running web applications, ie deal with overloading, provide monitoring, and sort out memory leaks and databases getting stuck. What I want, and probably many others, is an application stack that takes away all the problems of deploying web-apps - much as Rails takes away all the problems of writing them. All this vision stuff is much wider than just Mongrel - but I certainly see Mongrel as being part of the solution whatever that ends up being. What does the dog want to grow up to be? On 18/09/06, Zed Shaw wrote: > > * A "mostly C" version for Unix only that's fast as blazes. > -- Neil Wilson (neil at aldur.co.uk) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060918/e3969d20/attachment-0001.html From al-mongrelusers at none.at Mon Sep 18 06:57:27 2006 From: al-mongrelusers at none.at (Alexander Lazic) Date: Mon, 18 Sep 2006 12:57:27 +0200 Subject: [Mongrel] [ANN] Finally! Mongrel 0.3.13.4 Official (for Unix) In-Reply-To: <1158571601.8230.21.camel@localhost.localdomain> References: <1158571601.8230.21.camel@localhost.localdomain> Message-ID: <20060918105727.GA15039@none.at> On Mon 18.09.2006 02:26, Zed Shaw wrote: [snipped] >* Nginx module? Why nginx? Because I can read nginx code. Sad that I >can read a Russian's code better than the Apache code and that his >configuration file format is way better. ;-)) What do you mean with a 'nginx module' such as the 'perl module'?! Regards Aleks From eule at space.ch Mon Sep 18 09:04:13 2006 From: eule at space.ch (Kaspar Schiess) Date: Mon, 18 Sep 2006 15:04:13 +0200 Subject: [Mongrel] Question about mongrel_upload_progress In-Reply-To: <28F0A5AE-CB64-4B39-BFA4-7EAACE3A7136@amazing.com> References: <28F0A5AE-CB64-4B39-BFA4-7EAACE3A7136@amazing.com> Message-ID: Hi, Just the quick tip that I can see from what you write: Look for 'files/progress' and replace with 'creations/progress'. (Especially in the javascript) And, depending on setup, also look at my earlier post on the subject. best of luck kaspar From jgeiger at gmail.com Mon Sep 18 09:44:06 2006 From: jgeiger at gmail.com (Joey Geiger) Date: Mon, 18 Sep 2006 08:44:06 -0500 Subject: [Mongrel] [ANN] Finally! Mongrel 0.3.13.4 Official (for Unix) In-Reply-To: <20060918105727.GA15039@none.at> References: <1158571601.8230.21.camel@localhost.localdomain> <20060918105727.GA15039@none.at> Message-ID: <466af3440609180644j2f19e660ldeb254c55da28a35@mail.gmail.com> Re: different version numbers for unix/win32. I think this has been done with the mysql ruby module, and it's actually causing me problems. Every time I do a gem update, it thinks that the 2.7.1 is new on unix and tries to rebuild it, even though it's already at 2.7.0, which is the newest unix version. On 9/18/06, Alexander Lazic wrote: > On Mon 18.09.2006 02:26, Zed Shaw wrote: > [snipped] > > >* Nginx module? Why nginx? Because I can read nginx code. Sad that I > >can read a Russian's code better than the Apache code and that his > >configuration file format is way better. > > ;-)) > > What do you mean with a 'nginx module' such as the 'perl module'?! > > Regards > > Aleks > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From wyhaines at gmail.com Mon Sep 18 10:07:54 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 18 Sep 2006 08:07:54 -0600 Subject: [Mongrel] [ANN] Finally! Mongrel 0.3.13.4 Official (for Unix) In-Reply-To: References: <1158571601.8230.21.camel@localhost.localdomain> Message-ID: On 9/18/06, Neil Wilson wrote: > Is it time to step back and consider what Mongrel is about? Is it the I would agree with this. > wrapper around Rails (in which case couldn't it be a lot simpler. Automatic > cluster and eliminate the thread code so that Mongrel simply refuses > connections if the dispatcher is operational)? Or do you intend that it > should be more than that? Mongrel is being used as a preferred way for Nitro users to deploy Nitro apps, and it will soon become an important way for IOWA users to deploy apps in that framework, as well. In addition, Camping users employ it as a primary deployment vehicle, too. It is already heavily rails leaning, since that is the primary market, but from where I sit, it would be a shame to move more in that direction while sacraficing capability, as that starts to cut some of the other Mongrel users out of the picture. > What does the dog want to grow up to be? Good question. Kirk Haines From kevwil at gmail.com Mon Sep 18 10:45:00 2006 From: kevwil at gmail.com (Kevin Williams) Date: Mon, 18 Sep 2006 08:45:00 -0600 Subject: [Mongrel] [ANN] Finally! Mongrel 0.3.13.4 Official (for Unix) In-Reply-To: <466af3440609180644j2f19e660ldeb254c55da28a35@mail.gmail.com> References: <1158571601.8230.21.camel@localhost.localdomain> <20060918105727.GA15039@none.at> <466af3440609180644j2f19e660ldeb254c55da28a35@mail.gmail.com> Message-ID: <683a886f0609180745t6c334cc3g71d715d466469047@mail.gmail.com> The latest mysql code is version 2.7.1, but the only change from 2.7.0 is win32-related. Unfortunately, the win32 and ruby gems are separate projects, and the ruby gem has not been updated (likely because the only change is for win32). There is no need for mongrel to have different version numbers for win32, IMHO. On 9/18/06, Joey Geiger wrote: > Re: different version numbers for unix/win32. > > I think this has been done with the mysql ruby module, and it's > actually causing me problems. Every time I do a gem update, it thinks > that the 2.7.1 is new on unix and tries to rebuild it, even though > it's already at 2.7.0, which is the newest unix version. > > On 9/18/06, Alexander Lazic wrote: > > On Mon 18.09.2006 02:26, Zed Shaw wrote: > > [snipped] > > > > >* Nginx module? Why nginx? Because I can read nginx code. Sad that I > > >can read a Russian's code better than the Apache code and that his > > >configuration file format is way better. > > > > ;-)) > > > > What do you mean with a 'nginx module' such as the 'perl module'?! > > > > Regards > > > > Aleks > > _______________________________________________ > > 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 "Any sufficiently advanced technology is indistinguishable from Magic." - Arthur C. Clarke From me at seebq.com Mon Sep 18 11:04:40 2006 From: me at seebq.com (Charles Brian Quinn) Date: Mon, 18 Sep 2006 11:04:40 -0400 Subject: [Mongrel] [ANN] Finally! Mongrel 0.3.13.4 Official (for Unix) In-Reply-To: <466af3440609180644j2f19e660ldeb254c55da28a35@mail.gmail.com> References: <1158571601.8230.21.camel@localhost.localdomain> <20060918105727.GA15039@none.at> <466af3440609180644j2f19e660ldeb254c55da28a35@mail.gmail.com> Message-ID: <3a2de0cd0609180804q2569ee6ew229317b8b84436af@mail.gmail.com> Great work Zed, thanks for releasing this! on separate versioning: The flip-side to separate versioning is that you can write a script to automagically install everything for a new rails setup and not be prompted for the version of mongrel in the middle of your massive, long-running install script.... I believe. As for where to see mongrel go (at least on the rails side), I concur with simplicity. I'm thinking RAILS_ROOT/script/server mongrel starts mongrel on port 3000 and depdending on changing your own RAILS_ROOT/conf/mongrel.conf, starts up 1 or 5, prefixes, and all that other jazz, but is defaulted to start one on 3000 -- and you handle the load-balancing with whatever you want externally be it apache2 or nginx or pound or pen or lighttpd (mod_proxy_core). Of course this doesn't really help the other cool uses of mongrel and is a ruby/rails-centric view, but that's just me. cheers! On 9/18/06, Joey Geiger wrote: > Re: different version numbers for unix/win32. > > I think this has been done with the mysql ruby module, and it's > actually causing me problems. Every time I do a gem update, it thinks > that the 2.7.1 is new on unix and tries to rebuild it, even though > it's already at 2.7.0, which is the newest unix version. > > On 9/18/06, Alexander Lazic wrote: > > On Mon 18.09.2006 02:26, Zed Shaw wrote: > > [snipped] > > > > >* Nginx module? Why nginx? Because I can read nginx code. Sad that I > > >can read a Russian's code better than the Apache code and that his > > >configuration file format is way better. > > > > ;-)) > > > > What do you mean with a 'nginx module' such as the 'perl module'?! > > > > Regards > > > > Aleks > > _______________________________________________ > > 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 > -- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com From neil at aldur.co.uk Mon Sep 18 15:52:26 2006 From: neil at aldur.co.uk (Neil Wilson) Date: Mon, 18 Sep 2006 20:52:26 +0100 Subject: [Mongrel] [ANN] Finally! Mongrel 0.3.13.4 Official (for Unix) In-Reply-To: <3a2de0cd0609180804q2569ee6ew229317b8b84436af@mail.gmail.com> References: <1158571601.8230.21.camel@localhost.localdomain> <20060918105727.GA15039@none.at> <466af3440609180644j2f19e660ldeb254c55da28a35@mail.gmail.com> <3a2de0cd0609180804q2569ee6ew229317b8b84436af@mail.gmail.com> Message-ID: On 18/09/06, Charles Brian Quinn wrote: > > on separate versioning: > The flip-side to separate versioning is that you can write a script to > automagically install everything for a new rails setup and not be > prompted for the version of mongrel in the middle of your massive, > long-running install script.... I believe. You can already do this with a bit of Unix magic. See http://rubyforge.org/pipermail/mongrel-users/2006-June/000325.html -- > Neil Wilson (neil at aldur.co.uk) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060918/db3c7abb/attachment.html From neil at aldur.co.uk Mon Sep 18 15:55:23 2006 From: neil at aldur.co.uk (Neil Wilson) Date: Mon, 18 Sep 2006 20:55:23 +0100 Subject: [Mongrel] [ANN] Finally! Mongrel 0.3.13.4 Official (for Unix) In-Reply-To: <3a2de0cd0609180804q2569ee6ew229317b8b84436af@mail.gmail.com> References: <1158571601.8230.21.camel@localhost.localdomain> <20060918105727.GA15039@none.at> <466af3440609180644j2f19e660ldeb254c55da28a35@mail.gmail.com> <3a2de0cd0609180804q2569ee6ew229317b8b84436af@mail.gmail.com> Message-ID: On 18/09/06, Charles Brian Quinn wrote: > > on separate versioning: > The flip-side to separate versioning is that you can write a script to > automagically install everything for a new rails setup and not be > prompted for the version of mongrel in the middle of your massive, > long-running install script.... I believe. Or alternatively via Capistrano. (This is a def that is part of a Gem plugin). # Auto selects a gem from a list and installs it. # # *gem* has no mechanism on the command line of disambiguating builds for # different platforms, and instead asks the user. This method has the necessary # conversation to select the +version+ relevant to +platform+ (or the one nearest # the top of the list if you don't specify +version+). def select(package, version=nil, platform='ruby') selections={} cmd="#{GEM_INSTALL} #{if version then '-v '+version.to_s end} #{package}" sudo cmd do |channel, stream, data| data.each_line do | line | case line when /\s(\d+).*\(#{platform}\)/ if selections[channel[:host]].nil? selections[channel[:host]]=$1.dup+"\n" logger.info "Selecting #$&", "#{stream} :: #{channel[:host]}" end when /\s\d+\./ # Discard other selections from data stream when /^>/ channel.send_data selections[channel[:host]] logger.debug line, "#{stream} :: #{channel[:host]}" else logger.info line, "#{stream} :: #{channel[:host]}" end end end end -- Neil Wilson (neil at aldur.co.uk) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060918/b86f65b5/attachment.html From stonelists at gmail.com Mon Sep 18 16:03:39 2006 From: stonelists at gmail.com (Andrew Stone) Date: Mon, 18 Sep 2006 16:03:39 -0400 Subject: [Mongrel] href # Message-ID: Hello all, I've just upgraded to the latest mongrel and am having a problem with the following link: Manage... I'm now getting a routing error when I click on this link. It's trying to route to /Manage. Is there a different syntax I should be using? Btw, I didn't have an issue before the upgrade. System Details: Mongrel Web Server 0.3.13.4 Rails 1.1.6 Kubuntu Linux version (uname -rv): 2.6.15-26-386 #1 PREEMPT Fri Sep 8 19:55:17 UTC 2006 thanks, andy -- Andrew Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060918/3f4f0664/attachment-0001.html From steven at lumos.us Mon Sep 18 16:22:34 2006 From: steven at lumos.us (Steven Lumos) Date: Mon, 18 Sep 2006 13:22:34 -0700 Subject: [Mongrel] Random(?) action hanging Message-ID: <863baozzzp.fsf@bitty.lumos.us> Is this the behavior that supposedly indicates a problem with a particular action? Mongrel in development mode randomly hangs on random actions. Further requests cause USR1 logs like: Mon Sep 18 13:04:03 PDT 2006: 0 threads sync_waiting for /, 2 still active in mongrel. Mon Sep 18 13:07:52 PDT 2006: 1 threads sync_waiting for /public/stylesheets/table.css, 3 still active in mongrel. Mon Sep 18 13:08:21 PDT 2006: 2 threads sync_waiting for /, 4 still active in mongrel. 0 threads sync_waiting? Isn't that good? Sync waiting for a file? Is that supposed to happen? I thought that the USR1 output was supposed to help point out which action(s) had a problem, but the (random) action that actually caused the hang is never displayed, just whatever was the latest request after the hang. This doesn't seem to happen in production mode, at least it hasn't so far. It happens every few minutes in development, and sending INT to the process causes this: Thread # is too old, killing.Mon Sep 18 13:16:44 PDT 2006: Error calling Dispatcher.dispatch #) not locked.> /usr/local/lib/ruby/1.8/sync.rb:57:in `Fail' /usr/local/lib/ruby/1.8/sync.rb:63:in `Fail' /usr/local/lib/ruby/1.8/sync.rb:183:in `sync_unlock' /usr/local/lib/ruby/1.8/sync.rb:231:in `synchronize' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/rails.rb:83:in `process' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:580:in `process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:579:in `process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:673:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:267:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:266:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:127:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/command.rb:211:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:231/usr/local/bin/mongrel_rails:18 Thread # is too old, killing.Mon Sep 18 13:16:44 PDT 2006: Error calling Dispatcher.dispatch #) not locked.> [same backtrace as above] Has anybody else even seen this? Steve From stonelists at gmail.com Mon Sep 18 16:52:53 2006 From: stonelists at gmail.com (Andrew Stone) Date: Mon, 18 Sep 2006 16:52:53 -0400 Subject: [Mongrel] href # In-Reply-To: References: Message-ID: On 9/18/06, Andrew Stone wrote: > > Hello all, > > I've just upgraded to the latest mongrel and am having a problem with the > following link: > > Manage... > > I'm now getting a routing error when I click on this link. It's trying to > route to /Manage. Is there a different syntax I should be using? Btw, I > didn't have an issue before the upgrade. > > System Details: > > Mongrel Web Server 0.3.13.4 > Rails 1.1.6 > Kubuntu Linux version (uname -rv): 2.6.15-26-386 #1 PREEMPT Fri Sep 8 > 19:55:17 UTC 2006 > > thanks, > andy > > -- > Andrew Stone > Nevermind...stupid mistake on my part. Apologies, andy -- Andrew Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060918/54fda47b/attachment.html From paul at paulbutcher.com Mon Sep 18 20:55:06 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Tue, 19 Sep 2006 01:55:06 +0100 Subject: [Mongrel] Chunked transfer coding In-Reply-To: <1158571601.8230.21.camel@localhost.localdomain> Message-ID: <008101c6db86$40b0b160$7301a8c0@paullaptop> Under what circumstances (if any) will Mongrel use chunked transfer coding in responses? -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From zedshaw at zedshaw.com Mon Sep 18 21:20:18 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 18 Sep 2006 18:20:18 -0700 Subject: [Mongrel] Random(?) action hanging In-Reply-To: <863baozzzp.fsf@bitty.lumos.us> References: <863baozzzp.fsf@bitty.lumos.us> Message-ID: <1158628818.15906.36.camel@localhost.localdomain> On Mon, 2006-09-18 at 13:22 -0700, Steven Lumos wrote: > Is this the behavior that supposedly indicates a problem with a > particular action? Mongrel in development mode randomly hangs on > random actions. Further requests cause USR1 logs like: > > Mon Sep 18 13:04:03 PDT 2006: 0 threads sync_waiting for /, 2 still active in mongrel. > Mon Sep 18 13:07:52 PDT 2006: 1 threads sync_waiting for /public/stylesheets/table.css, 3 still active in mongrel. > Mon Sep 18 13:08:21 PDT 2006: 2 threads sync_waiting for /, 4 still active in mongrel. > Looks like / is blocking. Is this a Rails action? Also, you should probably run this in production mode as in development mode it's kind of slow and won't give you reasonable results. > 0 threads sync_waiting? Isn't that good? Sync waiting for a file? > Is that supposed to happen? > Yep, 0 is what you want, but you really want to start this up in production mode and then thrash the suspect action with something httperf. As for the file, this means that your apache instance isn't serving files but mongrel is. I suspect since you were running in development mode that you weren't behind a web server though. > I thought that the USR1 output was supposed to help point out which > action(s) had a problem, but the (random) action that actually caused > the hang is never displayed, just whatever was the latest request > after the hang. > The log doesn't display whichever is stuck, it just periodically lists how many requests are waiting for which actions. You gotta pound it or run it in heavy production to get a better sense. > This doesn't seem to happen in production mode, at least it hasn't so > far. It happens every few minutes in development, and sending INT to > the process causes this: > Yep, that's something blocking your threads. See what happens is you have a Rails action that's got things locked with Sync. A bunch of Mongrel threads pile up behind this sync lock waiting for rails to finish. Eventually when you shutdown with INT mongrel tries to do a graceful shutdown. It goes through all the active threads, sees that you've got a bunch that are really old, and then it starts killing them so you can get a stack trace. Hope that helps. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Tue Sep 19 02:41:36 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Mon, 18 Sep 2006 23:41:36 -0700 Subject: [Mongrel] Chunked transfer coding In-Reply-To: <008101c6db86$40b0b160$7301a8c0@paullaptop> References: <008101c6db86$40b0b160$7301a8c0@paullaptop> Message-ID: <1158648096.15906.43.camel@localhost.localdomain> On Tue, 2006-09-19 at 01:55 +0100, Paul Butcher wrote: > Under what circumstances (if any) will Mongrel use chunked transfer coding > in responses? It won't unless you write a handler that does it for you. Rails will never do it since the response from rails has to be completely buffered in case they change their mind and want to send out a different status or something else just as dumb. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From kraemer at webit.de Tue Sep 19 03:14:10 2006 From: kraemer at webit.de (Jens Kraemer) Date: Tue, 19 Sep 2006 09:14:10 +0200 Subject: [Mongrel] [ANN] Mongrel 0.13.3.4 Debian packages Message-ID: <20060919071410.GA21412@cordoba.webit.de> Hi folks, just wanted to let you know that I've updated the Mongrel Debian/Sarge packages. please see that blog post [1] for install instructions. If you already got them installed before, updating should be as easy as apt-get update apt-get upgrade btw: Zed, great work :-) cheers, Jens [1] http://www.jkraemer.net/2006/7/7/mongrel-apache-and-rails-on-debian-sarge -- webit! Gesellschaft f?r neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de Schnorrstra?e 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66 From paul at paulbutcher.com Tue Sep 19 05:25:36 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Tue, 19 Sep 2006 10:25:36 +0100 Subject: [Mongrel] Chunked transfer coding In-Reply-To: <1158648096.15906.43.camel@localhost.localdomain> Message-ID: <005501c6dbcd$913d2540$5f01a8c0@paullaptop> > On Tue, 2006-09-19 at 01:55 +0100, Paul Butcher wrote: > > Under what circumstances (if any) will Mongrel use chunked transfer > coding > > in responses? > > It won't unless you write a handler that does it for you. Rails will > never do it since the response from rails has to be completely buffered > in case they change their mind and want to send out a different status > or something else just as dumb. Thanks for the quick reply, Zed! -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From zedshaw at zedshaw.com Tue Sep 19 05:38:45 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Tue, 19 Sep 2006 02:38:45 -0700 Subject: [Mongrel] [ANN] Mongrel 0.13.3.4 Debian packages In-Reply-To: <20060919071410.GA21412@cordoba.webit.de> References: <20060919071410.GA21412@cordoba.webit.de> Message-ID: <1158658725.6278.4.camel@localhost.localdomain> On Tue, 2006-09-19 at 09:14 +0200, Jens Kraemer wrote: > Hi folks, > > just wanted to let you know that I've updated the Mongrel Debian/Sarge > packages. please see that blog post [1] for install instructions. > > If you already got them installed before, updating should be as easy as > > apt-get update > apt-get upgrade > > > btw: Zed, great work :-) Thanks for cooking these up Jens. It really helps the Debian folks. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From douglas.sellers at gmail.com Tue Sep 19 10:23:41 2006 From: douglas.sellers at gmail.com (douglas sellers) Date: Tue, 19 Sep 2006 10:23:41 -0400 Subject: [Mongrel] Upload Size Limiting Handler Message-ID: <4a5bd5380609190723x184aaab7w6d5ae21aab3e4755@mail.gmail.com> I have written a mongrel handler that monitors the content length of a given url's request and redirects them if they are over a certain limit. The idea is to throttle the maximum size of an uploaded file. Using the process method on HttpHandlerPlugin I am able to make this work the only downside is that the whole file is still uploaded. I would much prefer to inspect the http header params on the request_begins call and inform mongrel that there is no need to process that request any more. Is there any way to do this? I have glanced through both the handlers.rb and mongrel.rb source and I don't think that it is possible. While you can inspect the http header params in the request_begins there is no way to affect the actual processing of the request until the process method is called. Does anyone have any suggestions as to how I may be able to work around this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060919/d1e8ed7d/attachment.html From douglas.sellers at gmail.com Tue Sep 19 11:12:22 2006 From: douglas.sellers at gmail.com (douglas sellers) Date: Tue, 19 Sep 2006 11:12:22 -0400 Subject: [Mongrel] Upload Size Limiting Handler Message-ID: <4a5bd5380609190812h10cd7c63o437d3e101b9e583c@mail.gmail.com> I have written a mongrel handler that monitors the content length of a given url's request and redirects them if they are over a certain limit. The idea is to throttle the maximum size of an uploaded file. Using the process method on HttpHandlerPlugin I am able to make this work the only downside is that the whole file is still uploaded. I would much prefer to inspect the http header params on the request_begins call and inform mongrel that there is no need to process that request any more. Is there any way to do this? I have glanced through both the handlers.rb and mongrel.rb source and I don't think that it is possible. While you can inspect the http header params in the request_begins there is no way to affect the actual processing of the request until the process method is called. Does anyone have any suggestions as to how I may be able to work around this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060919/aef41729/attachment-0001.html From jacob at jacobatzen.dk Tue Sep 19 12:06:24 2006 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Tue, 19 Sep 2006 18:06:24 +0200 Subject: [Mongrel] Mongrel spewing backtraces and nanosleeping In-Reply-To: <20060915130211.GA14836@nezbo.dhcp.aub.dk> References: <20060913140021.GA1152@nezbo.dhcp.aub.dk> <1158186265.9628.10.camel@localhost.localdomain> <20060914092701.GA1382@nezbo.dhcp.aub.dk> <20060914152752.GA20862@nezbo.dhcp.aub.dk> <20060915130211.GA14836@nezbo.dhcp.aub.dk> Message-ID: <20060919160624.GA2229@nezbo.dhcp.aub.dk> On Fri, Sep 15, 2006 at 03:02:11PM +0200, Jacob Atzen wrote: > A little heads-up before the weekend, I've been running with the above > modifications and a few more to make the mutex calls run. So far I've > been processing ~28000 rails requests on a mongrel with a limit of 64 > processors. I will perform further testing and supply a full diff of my > modifications early next week. I have now performed some more extensive testing based on the suggestions by Kirk and have found Mongrel crashing when I raise the number of processors. I have attached a diff of my altarations to rails.rb in case anyone is interested. So alas, this did not cure the problems. I will try to upgrade mongrel to the new release and see how that holds up. Here is a snippet from mongrel.log up to the point where Mongrel crashed: Server overloaded with 512 processors (512 max). Dropping connection. Fri Sep 15 21:45:46 CEST 2006: Reaping 512 threads for slow workers because of 'max processors' Thread # is too old, killing. Fri Sep 15 21:45:46 CEST 2006: Error calling Dispatcher.dispatch # /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:637:in `lock' /usr/local/lib/ruby/1.8/thread.rb:133:in `synchronize' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/rails.rb:88:in `process' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:580:in `process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:579:in `process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:673:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:267:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:266:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:127:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/command.rb:203:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:231 /usr/local/bin/mongrel_rails:18 Thread # is too old, killing. Fri Sep 15 21:45:46 CEST 2006: ERROR: Mongrel timed out this thread: max processors Thread # is too old, killing. Thread # is too old, killing. Thread # is too old, killing. Thread # is too old, killing. Thread # is too old, killing. Thread # is too old, killing. Thread # is too old, killing. Thread # is too old, killing. /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:637:in `run': Mongrel timed out this thread: max processors (Mongrel::T imeoutError) from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:673:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:267:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:266:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:127:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/command.rb:203:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:231 from /usr/local/bin/mongrel_rails:18 -- Cheers, - Jacob Atzen -------------- next part -------------- 9c9 < require 'sync' --- > require 'thread' 45c45 < @guard = Sync.new --- > @guard = Mutex.new 83c83 < @guard.synchronize(:EX) { --- > @guard.synchronize { 100c100 < STDERR.puts "#{Time.now}: #{@guard.sync_waiting.length} threads sync_waiting for #{event}, #{self.listener.workers.list.length} still active in mongrel." --- > #STDERR.puts "#{Time.now}: #{@guard.sync_waiting.length} threads sync_waiting for #{event}, #{self.listener.workers.list.length} still active in mongrel." From why at ruby-lang.org Tue Sep 19 14:03:44 2006 From: why at ruby-lang.org (why the lucky stiff) Date: Tue, 19 Sep 2006 13:03:44 -0500 Subject: [Mongrel] Mongrel and Sandbox In-Reply-To: <1158445178.8624.7.camel@localhost.localdomain> References: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> <1158445178.8624.7.camel@localhost.localdomain> Message-ID: <20060919180344.GD51675@lstsv-3264.layeredtech.com> On Sat, Sep 16, 2006 at 03:19:38PM -0700, Zed Shaw wrote: > Yep, well for _why it's at least to run multiple separated camping apps, > but Rails is the holy grail for sure. Yes, I can now run Rails, Camping, Nitro, &c, &c, together in the same Mongrel. But the passing of the request into Rails is slow. It's very hacked right now, but I'm working on it now. * My edited mongrel_rails cycles through a directory, scanning for Rails apps and Camping apps, mounting what it can. * RailsDispatcher is edited to load the app inside a sandbox. * Also, I circumvent use of the Mongrel CGIWrapper, so I can pass the HTTP request string into the app and get back a response string. (It's just easier to pass strings between sandboxes rather than objects -- until I get a better proxy going between them.) I'm not sure where this stuff is going to go. I think maybe I'll make a dogbox gem or something that does all that until we're sure if it's really suitable for mongrel. Right now memory consumption is bad, but that's because Rails is loaded separately for each app. Once that's fixed, this is will be even more smart and/or stupid. _why From steven at lumos.us Tue Sep 19 14:03:35 2006 From: steven at lumos.us (Steven Lumos) Date: Tue, 19 Sep 2006 11:03:35 -0700 Subject: [Mongrel] Random(?) action hanging References: <863baozzzp.fsf@bitty.lumos.us> <1158628818.15906.36.camel@localhost.localdomain> Message-ID: <86ac4vybrc.fsf@bitty.lumos.us> Zed Shaw writes: > On Mon, 2006-09-18 at 13:22 -0700, Steven Lumos wrote: >> Is this the behavior that supposedly indicates a problem with a >> particular action? Mongrel in development mode randomly hangs on >> random actions. Further requests cause USR1 logs like: >> >> Mon Sep 18 13:04:03 PDT 2006: 0 threads sync_waiting for /, 2 still active in mongrel. >> Mon Sep 18 13:07:52 PDT 2006: 1 threads sync_waiting for /public/stylesheets/table.css, 3 still active in mongrel. >> Mon Sep 18 13:08:21 PDT 2006: 2 threads sync_waiting for /, 4 still active in mongrel. >> > > Looks like / is blocking. Is this a Rails action? Also, you should > probably run this in production mode as in development mode it's kind of > slow and won't give you reasonable results. > >> 0 threads sync_waiting? Isn't that good? Sync waiting for a file? >> Is that supposed to happen? >> > Yep, 0 is what you want, but you really want to start this up in > production mode and then thrash the suspect action with something > httperf. So far it hasn't happened in production mode. > As for the file, this means that your apache instance isn't serving > files but mongrel is. I suspect since you were running in development > mode that you weren't behind a web server though. Right. In production Apache is serving files. But does it make sense that Mongrel is failing to serve files? I thought only Rails was locked. >> I thought that the USR1 output was supposed to help point out which >> action(s) had a problem, but the (random) action that actually caused >> the hang is never displayed, just whatever was the latest request >> after the hang. >> > > The log doesn't display whichever is stuck, it just periodically lists > how many requests are waiting for which actions. You gotta pound it or > run it in heavy production to get a better sense. > >> This doesn't seem to happen in production mode, at least it hasn't so >> far. It happens every few minutes in development, and sending INT to >> the process causes this: >> > > Yep, that's something blocking your threads. See what happens is you > have a Rails action that's got things locked with Sync. A bunch of > Mongrel threads pile up behind this sync lock waiting for rails to > finish. Eventually when you shutdown with INT mongrel tries to do a > graceful shutdown. It goes through all the active threads, sees that > you've got a bunch that are really old, and then it starts killing them > so you can get a stack trace. > > Hope that helps. In this case only Mongrel is in the stack trace. I was especially wondering about #) not locked.> Is that expected? Thanks for the help. Steve > -- > Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From douglas.sellers at gmail.com Tue Sep 19 14:16:30 2006 From: douglas.sellers at gmail.com (douglas sellers) Date: Tue, 19 Sep 2006 14:16:30 -0400 Subject: [Mongrel] Upload Size Limiting Handler Message-ID: <4a5bd5380609191116v190cdf64l70296dd4466fda18@mail.gmail.com> I have written a mongrel handler that monitors the content length of a given url's request and redirects them if they are over a certain limit. The idea is to throttle the maximum size of an uploaded file. Using the process method on HttpHandlerPlugin I am able to make this work the only downside is that the whole file is still uploaded. I would much prefer to inspect the http header params on the request_begins call and inform mongrel that there is no need to process that request any more. Is there any way to do this? I have glanced through both the handlers.rb and mongrel.rb source and I don't think that it is possible. While you can inspect the http header params in the request_begins there is no way to affect the actual processing of the request until the process method is called. Does anyone have any suggestions as to how I may be able to work around this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060919/6ef8d69a/attachment.html From kovacs at gmail.com Tue Sep 19 21:51:04 2006 From: kovacs at gmail.com (Michael Kovacs) Date: Tue, 19 Sep 2006 18:51:04 -0700 Subject: [Mongrel] [Slightly OT] Uploading files with firefox Message-ID: <0C66E8B1-0EF1-4D01-BF26-566A12D46D05@gmail.com> I have been successfully using the latest mongrel and upload progress plugin with safari but firefox seems to have some issues with any request that takes longer than 5 seconds to complete. You get the "Warning: Unresponsive Script" screen. Apparently this problem is fixable by following this: http://computer-vet.com/weblog/2006/04/28/ firefox_warning_unresponsive_script.html Telling my users to go there and do that is not something that I'm willing to do, so I'm wondering if anyone out there knows how to change this on the fly or if there's some other trick to make firefox behave during a file upload? Or are others not seeing this problem at all? -Michael http://javathehutt.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060919/53c8b498/attachment.html From brad at bradediger.com Tue Sep 19 23:28:37 2006 From: brad at bradediger.com (Brad Ediger) Date: Tue, 19 Sep 2006 22:28:37 -0500 Subject: [Mongrel] [Slightly OT] Uploading files with firefox In-Reply-To: <0C66E8B1-0EF1-4D01-BF26-566A12D46D05@gmail.com> References: <0C66E8B1-0EF1-4D01-BF26-566A12D46D05@gmail.com> Message-ID: <9BCE20D3-69DA-49AA-A0A5-07DF9226CD4A@bradediger.com> I'm not seeing this problem at all. I'm using mongrel 0.3.13.3 and mongrel_upload_progress 0.1. Firefox 1.5.0.7. I'm not using the helpers, however -- I'm using some heavily-hacked code on the client side because of some special requirements. Contact me off-list to discuss the code -- it's not available for public consumption (yet, hopefully.) I don't see why you should have a long-running script anyway. The form should post to an iframe and then set up a PeriodicalExecuter (which in turn uses setInterval). If I'm not mistaken, that function should return immediately. As long as you're using asynchronous requests for the updates, you shouldn't block. But I have been known to be wrong before, and I could be wrong now. ;-) --be On Sep 19, 2006, at 8:51 PM, Michael Kovacs wrote: > I have been successfully using the latest mongrel and upload > progress plugin with safari but firefox seems to have some issues > with any request > that takes longer than 5 seconds to complete. You get the "Warning: > Unresponsive Script" screen. Apparently this problem is fixable by > following this: > > http://computer-vet.com/weblog/2006/04/28/ > firefox_warning_unresponsive_script.html > > Telling my users to go there and do that is not something that I'm > willing to do, so I'm wondering if anyone out there knows how to > change this on the > fly or if there's some other trick to make firefox behave during a > file upload? Or are others not seeing this problem at all? > > -Michael > http://javathehutt.blogspot.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060919/b8ef8bdd/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060919/b8ef8bdd/attachment-0001.bin From kovacs at gmail.com Wed Sep 20 01:35:29 2006 From: kovacs at gmail.com (Michael Kovacs) Date: Tue, 19 Sep 2006 22:35:29 -0700 Subject: [Mongrel] [Slightly OT] Uploading files with firefox In-Reply-To: <9BCE20D3-69DA-49AA-A0A5-07DF9226CD4A@bradediger.com> References: <0C66E8B1-0EF1-4D01-BF26-566A12D46D05@gmail.com> <9BCE20D3-69DA-49AA-A0A5-07DF9226CD4A@bradediger.com> Message-ID: Well even if I pull all the javascript code and just do a straight form post with no progress I get this behavior in firefox. The upload request is taking more than 5 seconds so firefox is popping up that dialog. IE and safari work fine and for the first time ever it's firefox that I'm cursing instead of IE or safari. Go figure :-) -Michael http://javathehutt.blogspot.com On Sep 19, 2006, at 8:28 PM, Brad Ediger wrote: > I'm not seeing this problem at all. I'm using mongrel 0.3.13.3 and > mongrel_upload_progress 0.1. Firefox 1.5.0.7. I'm not using the > helpers, however -- I'm using some heavily-hacked code on the > client side because of some special requirements. Contact me off- > list to discuss the code -- it's not available for public > consumption (yet, hopefully.) > > I don't see why you should have a long-running script anyway. The > form should post to an iframe and then set up a PeriodicalExecuter > (which in turn uses setInterval). If I'm not mistaken, that > function should return immediately. As long as you're using > asynchronous requests for the updates, you shouldn't block. But I > have been known to be wrong before, and I could be wrong now. ;-) > > --be > > On Sep 19, 2006, at 8:51 PM, Michael Kovacs wrote: > >> I have been successfully using the latest mongrel and upload >> progress plugin with safari but firefox seems to have some issues >> with any request >> that takes longer than 5 seconds to complete. You get the >> "Warning: Unresponsive Script" screen. Apparently this problem is >> fixable by following this: >> >> http://computer-vet.com/weblog/2006/04/28/ >> firefox_warning_unresponsive_script.html >> >> Telling my users to go there and do that is not something that I'm >> willing to do, so I'm wondering if anyone out there knows how to >> change this on the >> fly or if there's some other trick to make firefox behave during a >> file upload? Or are others not seeing this problem at all? >> >> -Michael >> http://javathehutt.blogspot.com >> >> > _______________________________________________ > 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/20060919/79c1a506/attachment.html From john at fivesquaresoftware.com Wed Sep 20 03:07:02 2006 From: john at fivesquaresoftware.com (John Clayton) Date: Wed, 20 Sep 2006 00:07:02 -0700 Subject: [Mongrel] Mongrel and Sandbox In-Reply-To: <20060919180344.GD51675@lstsv-3264.layeredtech.com> References: <20060916172828.66448.qmail@web38613.mail.mud.yahoo.com> <1158445178.8624.7.camel@localhost.localdomain> <20060919180344.GD51675@lstsv-3264.layeredtech.com> Message-ID: <7159D481-5172-469A-AAFF-525473745174@fivesquaresoftware.com> I'd volunteer to help you work on/debug this as I think this is applicable to my post about mass rails hosting with mongrel. John On Sep 19, 2006, at 11:03 AM, why the lucky stiff wrote: > On Sat, Sep 16, 2006 at 03:19:38PM -0700, Zed Shaw wrote: >> Yep, well for _why it's at least to run multiple separated camping >> apps, >> but Rails is the holy grail for sure. > > Yes, I can now run Rails, Camping, Nitro, &c, &c, together in the > same Mongrel. > But the passing of the request into Rails is slow. It's very > hacked right now, > but I'm working on it now. > > * My edited mongrel_rails cycles through a directory, scanning for > Rails apps > and Camping apps, mounting what it can. > * RailsDispatcher is edited to load the app inside a sandbox. > * Also, I circumvent use of the Mongrel CGIWrapper, so I can pass > the HTTP > request string into the app and get back a response string. > (It's just > easier to pass strings between sandboxes rather than objects -- > until I > get a better proxy going between them.) > > I'm not sure where this stuff is going to go. I think maybe I'll > make a dogbox > gem or something that does all that until we're sure if it's really > suitable for > mongrel. > > Right now memory consumption is bad, but that's because Rails is > loaded > separately for each app. Once that's fixed, this is will be even > more smart > and/or stupid. > > _why > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From paul at paulbutcher.com Wed Sep 20 06:18:53 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Wed, 20 Sep 2006 11:18:53 +0100 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution Message-ID: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> We have been searching for a Rails deployment architecture which works for us for some time. We've recently moved from Apache 1.3 + FastCGI to Apache 2.2 + mod_proxy_balancer + mongrel_cluster, and it's a significant improvement. But it still exhibits serious performance problems. We have the beginnings of a fix that we would like to share. To illustrate the problem, imagine a 2 element mongrel cluster running a Rails app containing the following simple controller: class HomeController < ApplicationController def fast sleep 1 render :text => "I'm fast" end def slow sleep 10 render :text => "I'm slow" end end and the following test app #!/usr/bin/env ruby require File.dirname(__FILE__) + '/config/boot' require File.dirname(__FILE__) + '/config/environment' end_time = 1.minute.from_now fast_count = 0 slow_count = 0 fastthread = Thread.start do while Time.now < end_time do Net::HTTP.get 'localhost', '/home/fast' fast_count += 1 end end slowthread = Thread.start do while Time.now < end_time do Net::HTTP.get 'localhost', '/home/slow' slow_count += 1 end end fastthread.join slowthread.join puts "Fast: #{fast_count}" puts "Slow: #{slow_count}" In this scenario, there will be two requests outstanding at any time, one "fast" and one "slow". You would expect approximately 60 fast and 6 slow GETs to complete over the course of a minute. This is not what happens; approximately 12 fast and 6 slow GETs complete per minute. The reason is that mod_proxy_balancer assumes that it can send multiple requests to each mongrel and fast requests end up waiting for slow requests, even if there is an idle mongrel server available. We've experimented with various different configurations for mod_proxy_balancer without successfully solving this issue. As far as we can tell, all other popular load balancers (Pound, Pen, balance) behave in roughly the same way. This is causing us real problems. Our user interface is very time-sensitive. For common user actions, a page refresh delay of more than a couple of seconds is unacceptable. What we're finding is that if we have (say) a reporting page which takes 10 seconds to display (an entirely acceptable delay for a rarely-used report) then our users are seeing similar delays on pages which should be virtually instantaneous (and would be, if their requests were directed to idle servers). Worse, we're occasionally seeing unnecessary timeouts because requests are queuing up on one server. The real solution to the problem would be to remove Rails' inability to handle more than one thread. In the absence of that solution, however, we've implemented (in Ruby) what might be the world's smallest load-balancer. It only ever sends a single request to each member of the cluster at a time. It's called HighWire and is available on RubyForge (no Gem yet - it's on the list of things to do!): svn checkout svn://rubyforge.org/var/svn/highwire Using this instead of mod_proxy_balancer, and running the same test script above, we see approximately 54 fast and 6 slow requests per minute. HighWire is very young and has a way to go. It's not had any serious optimization or testing, and there are a bunch of things that need doing before it can really be considered production ready. But it does work for us, and does produce a significant performance improvement. Please check it out and let us know what you think. -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From brad at bradediger.com Wed Sep 20 10:44:17 2006 From: brad at bradediger.com (Brad Ediger) Date: Wed, 20 Sep 2006 09:44:17 -0500 Subject: [Mongrel] [Slightly OT] Uploading files with firefox In-Reply-To: References: <0C66E8B1-0EF1-4D01-BF26-566A12D46D05@gmail.com> <9BCE20D3-69DA-49AA-A0A5-07DF9226CD4A@bradediger.com> Message-ID: Can you post sample code? My Firefox behaves fine with long-running HTTP requests. Perhaps Mongrel is taking too long to respond? On Sep 20, 2006, at 12:35 AM, Michael Kovacs wrote: > Well even if I pull all the javascript code and just do a straight > form post with no progress I get this behavior in firefox. The > upload request is taking more than 5 seconds > so firefox is popping up that dialog. IE and safari work fine and > for the first time ever it's firefox that I'm cursing instead of IE > or safari. Go figure :-) > > -Michael > http://javathehutt.blogspot.com > > On Sep 19, 2006, at 8:28 PM, Brad Ediger wrote: > >> I'm not seeing this problem at all. I'm using mongrel 0.3.13.3 and >> mongrel_upload_progress 0.1. Firefox 1.5.0.7. I'm not using the >> helpers, however -- I'm using some heavily-hacked code on the >> client side because of some special requirements. Contact me off- >> list to discuss the code -- it's not available for public >> consumption (yet, hopefully.) >> >> I don't see why you should have a long-running script anyway. The >> form should post to an iframe and then set up a PeriodicalExecuter >> (which in turn uses setInterval). If I'm not mistaken, that >> function should return immediately. As long as you're using >> asynchronous requests for the updates, you shouldn't block. But I >> have been known to be wrong before, and I could be wrong now. ;-) >> >> --be >> >> On Sep 19, 2006, at 8:51 PM, Michael Kovacs wrote: >> >>> I have been successfully using the latest mongrel and upload >>> progress plugin with safari but firefox seems to have some issues >>> with any request >>> that takes longer than 5 seconds to complete. You get the >>> "Warning: Unresponsive Script" screen. Apparently this problem is >>> fixable by following this: >>> >>> http://computer-vet.com/weblog/2006/04/28/ >>> firefox_warning_unresponsive_script.html >>> >>> Telling my users to go there and do that is not something that >>> I'm willing to do, so I'm wondering if anyone out there knows how >>> to change this on the >>> fly or if there's some other trick to make firefox behave during >>> a file upload? Or are others not seeing this problem at all? >>> >>> -Michael >>> http://javathehutt.blogspot.com >>> >>> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060920/b33de72d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060920/b33de72d/attachment-0001.bin From technoweenie at gmail.com Wed Sep 20 10:59:47 2006 From: technoweenie at gmail.com (Rick Olson) Date: Wed, 20 Sep 2006 09:59:47 -0500 Subject: [Mongrel] boy, that mongrel_upload_progress handler sucks! Message-ID: <48fe25b0609200759g4f8fbf0aq126dde8f3891105d@mail.gmail.com> I started actually using the upload progress handler, and noticed it was leaking memory over time. Looking at the code, I noticed that cancelled uploads weren't being cleaned up. I bugged Zed about adding a request_abort callback to handlers, but I found a simple way to monkey patch that in: # config/mongrel_upload_progress.conf # yes, this file is being used with -S meaning it's an actual ruby file. # So, why don't I use the rb extension? Hell if I know :) Mongrel::HttpHandler.class_eval do # add the default stub method def request_aborted(params) end end # patch the monkey Mongrel::HttpRequest.class_eval do def initialize_with_abort(params, socket, dispatcher) initialize_without_abort(params, socket, dispatcher) dispatcher.request_aborted(params) if @body.nil? && dispatcher end alias_method :initialize_without_abort, :initialize alias_method :initialize, :initialize_with_abort end Set up the handler uri "/", :handler => plugin("/handlers/upload", :path_info => '/upload'), :in_front => true # add the callback to the actual handler. ::Upload.class_eval do def request_aborted(params) return unless params['PATH_INFO'] == @path_info && params[Mongrel::Const::REQUEST_METHOD] == 'POST' && upload_id = Mongrel::HttpRequest.query_parse(params['QUERY_STRING'])['upload_id'] instance_variable_set(checked_var(upload_id), nil) Mongrel::Uploads.finish(upload_id) end end I'm going to work this into svn. But, there's another issue. Using instance vars means you're basically adding random instance vars into the class. They're set to nil on finish, but this still eats up memory. _why's original version used hashes, but I had some nasty locking isuses on multiple uploads. I replaced this with the current instance variable scheme, which helped with the locking, but now leaks. I think the locking issue is fixed now by setting the default marking frequency to 3 seconds. So, I'm going to try and go back to the hashes method. I did some quick tests in the console like this: class Leaker def key Time.now.to_i.to_s.split('').sort_by { rand }.join end def inst_var instance_variable_set("@key_#{key}", nil) end def rem_var k = "@key_#{key}" instance_variable_set(k, Time.now) remove_instance_variable(k) end def hash @hash ||= {} k = key @hash[k] = Time.now @hash.delete k end end l = Leaker.new while 1; l.inst_var; end # eats memory! while 1; l.rem_var; end # eats memory! while 1; l.hash; end # stays at a constant 2mb -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com From kovacs at gmail.com Wed Sep 20 12:59:51 2006 From: kovacs at gmail.com (Michael Kovacs) Date: Wed, 20 Sep 2006 09:59:51 -0700 Subject: [Mongrel] [Slightly OT] Uploading files with firefox In-Reply-To: References: <0C66E8B1-0EF1-4D01-BF26-566A12D46D05@gmail.com> <9BCE20D3-69DA-49AA-A0A5-07DF9226CD4A@bradediger.com> Message-ID: <0E2AF10A-B127-4CA3-9146-133990AF7D8C@gmail.com> I'm using the sample code that's on the mongrel documentation page. -Michael http://javathehutt.blogspot.com On Sep 20, 2006, at 7:44 AM, Brad Ediger wrote: > Can you post sample code? My Firefox behaves fine with long-running > HTTP requests. > > Perhaps Mongrel is taking too long to respond? > > On Sep 20, 2006, at 12:35 AM, Michael Kovacs wrote: > >> Well even if I pull all the javascript code and just do a straight >> form post with no progress I get this behavior in firefox. The >> upload request is taking more than 5 seconds >> so firefox is popping up that dialog. IE and safari work fine and >> for the first time ever it's firefox that I'm cursing instead of >> IE or safari. Go figure :-) >> >> -Michael >> http://javathehutt.blogspot.com >> >> On Sep 19, 2006, at 8:28 PM, Brad Ediger wrote: >> >>> I'm not seeing this problem at all. I'm using mongrel 0.3.13.3 >>> and mongrel_upload_progress 0.1. Firefox 1.5.0.7. I'm not using >>> the helpers, however -- I'm using some heavily-hacked code on the >>> client side because of some special requirements. Contact me off- >>> list to discuss the code -- it's not available for public >>> consumption (yet, hopefully.) >>> >>> I don't see why you should have a long-running script anyway. The >>> form should post to an iframe and then set up a >>> PeriodicalExecuter (which in turn uses setInterval). If I'm not >>> mistaken, that function should return immediately. As long as >>> you're using asynchronous requests for the updates, you shouldn't >>> block. But I have been known to be wrong before, and I could be >>> wrong now. ;-) >>> >>> --be >>> >>> On Sep 19, 2006, at 8:51 PM, Michael Kovacs wrote: >>> >>>> I have been successfully using the latest mongrel and upload >>>> progress plugin with safari but firefox seems to have some >>>> issues with any request >>>> that takes longer than 5 seconds to complete. You get the >>>> "Warning: Unresponsive Script" screen. Apparently this problem >>>> is fixable by following this: >>>> >>>> http://computer-vet.com/weblog/2006/04/28/ >>>> firefox_warning_unresponsive_script.html >>>> >>>> Telling my users to go there and do that is not something that >>>> I'm willing to do, so I'm wondering if anyone out there knows >>>> how to change this on the >>>> fly or if there's some other trick to make firefox behave during >>>> a file upload? Or are others not seeing this problem at all? >>>> >>>> -Michael >>>> http://javathehutt.blogspot.com >>>> >>>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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/20060920/08521452/attachment.html From kraemer at webit.de Wed Sep 20 13:07:01 2006 From: kraemer at webit.de (Jens Kraemer) Date: Wed, 20 Sep 2006 19:07:01 +0200 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution In-Reply-To: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> References: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> Message-ID: <20060920170701.GS31018@cordoba.webit.de> Hi! On Wed, Sep 20, 2006 at 11:18:53AM +0100, Paul Butcher wrote: > We have been searching for a Rails deployment architecture which works for > us for some time. We've recently moved from Apache 1.3 + FastCGI to Apache > 2.2 + mod_proxy_balancer + mongrel_cluster, and it's a significant > improvement. But it still exhibits serious performance problems. hey, cool, I really like the simplicity of your approach. However I tried to solve your problem with Pen, and here's what I got: standard pen setup, no special options besides 'no sticky sessions' and 'non blocking mode': pen -fndr 9000 localhost:9001 localhost:9002 Fast: 13 Slow: 6 just as predicted by you. However, if I limit *one* of the mongrels to 1 connection at a time, I get this: pen -fdnr 9000 localhost:9001:1 localhost:9002 Fast: 59 Slow: 6 When I limit both backend servers to only 1 connection the test script always bails out since pen doesn't seem to keep connections like you do in your queue, but closes them if it finds no server to dispatch to, so it needs at least one backend process to pile up connections at when the need arises. I have no idea if this is a solution that would be useful under real life conditions, but found the behaviour quite interesting. I also raised the number of threads requesting the fast action, which led to more successful requests on the fast action, and (sometimes) less on the slow one, i.e. Fast: 67-69 Slow: 5-6 with 10 threads accessing the fast action. Whatever load balancing you use, you'll always need to have more Mongrels than there are concurrent requests for 'slow' actions to avoid delays for clients requesting a 'fast' action. So maybe, if the slow actions are well known, one could just reserve a pool of Mongrels for these slow actions, and another one for the fast ones... Jens -- webit! Gesellschaft f?r neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de Schnorrstra?e 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66 From g.vishnu at gmail.com Wed Sep 20 13:36:41 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Wed, 20 Sep 2006 23:06:41 +0530 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution In-Reply-To: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> References: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> Message-ID: On 9/20/06, Paul Butcher wrote: > > [..] > implemented (in Ruby) what might be the world's smallest load-balancer. It > only ever sends a single request to each member of the cluster at a time. > [..] What happens to the other requests? Are they queued up? And if so, how does that solve the problem? Please check it out and let us know what you think. Will do. Looks interesting :-) Vish -- > paul.butcher->msgCount++ > > Snetterton, Castle Combe, Cadwell Park... > Who says I have a one track mind? > > MSN: paul at paulbutcher.com > AIM: paulrabutcher > Skype: paulrabutcher > LinkedIn: https://www.linkedin.com/in/paulbutcher > > _______________________________________________ > 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/20060920/d5edf328/attachment.html From zedshaw at zedshaw.com Wed Sep 20 15:21:27 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 20 Sep 2006 12:21:27 -0700 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution In-Reply-To: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> References: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> Message-ID: <1158780087.27841.24.camel@localhost.localdomain> On Wed, 2006-09-20 at 11:18 +0100, Paul Butcher wrote: First off, it's awesome that you're writing a solution to your problem. Very cool and looks like it didn't take you much. Maybe I'll work up something in C that does this since it's a common requested solution. > This is causing us real problems. Our user interface is very time-sensitive. > For common user actions, a page refresh delay of more than a couple of > seconds is unacceptable. But, if your interface is time sensitive then why does it have actions that take too much time? See the conundrum there? > What we're finding is that if we have (say) a > reporting page which takes 10 seconds to display (an entirely acceptable > delay for a rarely-used report) .... See, right there. "reporting" is usually a goldmine for stuff you can push out to a backgroundrb processors. The best pattern here is not "ok, let's write a load balancer in ruby so all processes are as fast as one ruby process" but instead to redesign that rails action to use backgroundrb. This will get you over the hump, but you'll seriously have to look at carving those unpredictable actions out and making them shorter. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From paul at paulbutcher.com Wed Sep 20 15:45:30 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Wed, 20 Sep 2006 20:45:30 +0100 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution Message-ID: <000001c6dced$54933050$7301a8c0@paullaptop> Vishnu Gopal wrote: > What happens to the other requests? Are they queued up? And if so, how > does that solve the problem? It depends on what you mean by "the other" requests. The problem with mod_proxy_balancer is that you can get into a situation where all mongrels are idle but one, but it sends the next request to the busy mongrel, not one of the idle mongrels. HighWire will always send each incoming request to an idle mongrel if there are any. If there aren't any, then yes, it will queue them up. But it will only do so if there aren't any idle mongrels. That's the difference. -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From rise at knavery.net Thu Sep 21 14:48:50 2006 From: rise at knavery.net (Jonathan) Date: Thu, 21 Sep 2006 12:48:50 -0600 (MDT) Subject: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- QUERY_STRING Fixed In-Reply-To: <1155773674.6122.13.camel@localhost.localdomain> References: <1155772406.6122.11.camel@localhost.localdomain> <1155773674.6122.13.camel@localhost.localdomain> Message-ID: <20060921.124850.78713392.rise@knavery.net> On Wed, 16 Aug 2006 17:14:34 -0700 Zed Shaw wrote: > Correction, NOW the win32 gems are up. > I really gotta either get vmware or wine going for cross builds so I > can automate this. If it'd help I've got a VMware Workstation license sitting unused I'd be happy to give you the key for. I'm not sure if the EULA specifically allows or forbids this, but I know someone at the director level over there and I'm comfortable with the ethics after a few of the conversations we've had. Frankly for every version from 2 on I've bought a license for a project, used it for a couple of months maximum, and stuck it on the shelf. -- Jonathan Conway rise at knavery.net From paul at paulbutcher.com Wed Sep 20 16:14:40 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Wed, 20 Sep 2006 21:14:40 +0100 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution Message-ID: <000d01c6dcf1$6799ce80$7301a8c0@paullaptop> Zed Shaw wrote > But, if your interface is time sensitive then why does it have actions > that take too much time? See the conundrum there? I was kinda expecting that response, Zed, but I didn't want to rob you of the pleasure of saying it ;-) We are in fact using backgroundrb for a number of long-running actions. It's fantastic, but it isn't ever going to solve the problem for us completely. There are a whole bunch of reasons, which may be specific to our particular application, but I doubt it. First the less convincing arguments: 1) We're lazy (in a good way). Our application is used by hundreds of our employees, 24 hours a day. We, correctly, invest a great deal of time making sure that the things that they do over and over again are as efficient as they possibly can be. We don't, however, believe that it's appropriate for us to spend time optimising things which are only used by one or two guys once or twice a day. It's not as if we have a lack of things to spend our time on, and we'd rather spend that time on things that really matter, rather than optimising things which only need to be optimised because the performance characteristics of Rails mean that one poorly performing action results in *all* actions performing poorly. 2) We're not infallible. Sometimes we screw up and release a version of the software where one of our actions takes longer than it should. This is bad if it only affects the action we screwed up, but if that's all it does then it's not a disaster. If one slow action screws up *all* the actions, however, that is a disaster. 3) Even if we spend all of the time we possibly can optimising actions, different actions will always take different amounts of time to execute. It's not as if there's "one true" execution time for an action. The bad effects become apparent whenever you have any two actions which take noticeably different amounts of time to execute. Yes, in the example that I gave it was 1 second and 10 seconds. But the same basic effect would be there if we were talking about 1ms and 10ms. Those arguments would be enough, I believe. But in our case there's one much stronger argument which trumps all the above IMHO: 4) It's not possible to predict the time that an action, even a heavily optimised one, will take. The vagaries of cacheing, swapping etc mean that this is simply out of our hands. In our case, for example, many of our actions involve fulltext searches of the database (we have no choice about this - it's fundamental to the nature of what we do). The performance of a fulltext search is *extremely* unpredictable (in MySQL anyway). There can be occasions where the first time a particular search is done, it takes 10 seconds. The second time, because the database has "got the idea", it can take a few milliseconds. Backgroundrb cannot solve this problem - if we sent all of these actions to backgroundrb, pretty much *every* action would end up being sent to backgroundrb and then we end up with a very similar load balancing problem - it just becomes a problem of load balancing to backgroundrb instead of to mongrel. Make sense? -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From brad at bradediger.com Wed Sep 20 16:18:05 2006 From: brad at bradediger.com (Brad Ediger) Date: Wed, 20 Sep 2006 15:18:05 -0500 Subject: [Mongrel] [Slightly OT] Uploading files with firefox In-Reply-To: <0E2AF10A-B127-4CA3-9146-133990AF7D8C@gmail.com> References: <0C66E8B1-0EF1-4D01-BF26-566A12D46D05@gmail.com> <9BCE20D3-69DA-49AA-A0A5-07DF9226CD4A@bradediger.com> <0E2AF10A-B127-4CA3-9146-133990AF7D8C@gmail.com> Message-ID: Well, a quick Google search seems to indicate that this is a widespread problem with uploads and FF/1.5. (Enough so that some sites list this issue in their FAQs). It seems to happen under one of two circumstances: 1) Script takes too long to execute 2) Server takes too long to respond or is not available. Barring #2, I would see if there are other scripts running concurrently that might be blocked by a long file upload. I would imagine that if you had a number of JS-intensive extensions installed (View Formatted Source, Web Developer, Adblock, etc.), they might be causing this error. Just a guess, though... I'm out of my league now. I have my dom.max_script_run_time set to 10 and I only very rarely get this warning while a script is still running (i.e., not locked up.) --be On Sep 20, 2006, at 11:59 AM, Michael Kovacs wrote: > I'm using the sample code that's on the mongrel documentation page. > > -Michael > http://javathehutt.blogspot.com > > On Sep 20, 2006, at 7:44 AM, Brad Ediger wrote: > >> Can you post sample code? My Firefox behaves fine with long- >> running HTTP requests. >> >> Perhaps Mongrel is taking too long to respond? >> >> On Sep 20, 2006, at 12:35 AM, Michael Kovacs wrote: >> >>> Well even if I pull all the javascript code and just do a >>> straight form post with no progress I get this behavior in >>> firefox. The upload request is taking more than 5 seconds >>> so firefox is popping up that dialog. IE and safari work fine and >>> for the first time ever it's firefox that I'm cursing instead of >>> IE or safari. Go figure :-) >>> >>> -Michael >>> http://javathehutt.blogspot.com >>> >>> On Sep 19, 2006, at 8:28 PM, Brad Ediger wrote: >>> >>>> I'm not seeing this problem at all. I'm using mongrel 0.3.13.3 >>>> and mongrel_upload_progress 0.1. Firefox 1.5.0.7. I'm not using >>>> the helpers, however -- I'm using some heavily-hacked code on >>>> the client side because of some special requirements. Contact me >>>> off-list to discuss the code -- it's not available for public >>>> consumption (yet, hopefully.) >>>> >>>> I don't see why you should have a long-running script anyway. >>>> The form should post to an iframe and then set up a >>>> PeriodicalExecuter (which in turn uses setInterval). If I'm not >>>> mistaken, that function should return immediately. As long as >>>> you're using asynchronous requests for the updates, you >>>> shouldn't block. But I have been known to be wrong before, and I >>>> could be wrong now. ;-) >>>> >>>> --be >>>> >>>> On Sep 19, 2006, at 8:51 PM, Michael Kovacs wrote: >>>> >>>>> I have been successfully using the latest mongrel and upload >>>>> progress plugin with safari but firefox seems to have some >>>>> issues with any request >>>>> that takes longer than 5 seconds to complete. You get the >>>>> "Warning: Unresponsive Script" screen. Apparently this problem >>>>> is fixable by following this: >>>>> >>>>> http://computer-vet.com/weblog/2006/04/28/ >>>>> firefox_warning_unresponsive_script.html >>>>> >>>>> Telling my users to go there and do that is not something that >>>>> I'm willing to do, so I'm wondering if anyone out there knows >>>>> how to change this on the >>>>> fly or if there's some other trick to make firefox behave >>>>> during a file upload? Or are others not seeing this problem at >>>>> all? >>>>> >>>>> -Michael >>>>> http://javathehutt.blogspot.com >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060920/238e7354/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060920/238e7354/attachment-0001.bin From paul at paulbutcher.com Wed Sep 20 16:18:20 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Wed, 20 Sep 2006 21:18:20 +0100 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn'twork for us and the beginning of a solution In-Reply-To: <20060920170701.GS31018@cordoba.webit.de> Message-ID: <001401c6dcf1$ea7f7b10$7301a8c0@paullaptop> Jens Kraemer wrote: > However, if I limit *one* of the mongrels to 1 connection at a time, I get > this: > pen -fdnr 9000 localhost:9001:1 localhost:9002 > Fast: 59 > Slow: 6 That's interesting! Thanks. I did try a similar configuration of mod_proxy_balancer, but it didn't have the same effect. Maybe I'll play with Pen some more... > So maybe, if the slow actions are well known, one could just reserve a > pool of Mongrels for these slow actions, and another one for the fast > ones... We did consider this approach. It "feels wrong" to us though, and as I said in my response to Zed's mail, for our application at least it's not always possible to identify "slow" actions ahead of time :-( Thanks for the information though! -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From jsierles at gmail.com Wed Sep 20 18:14:13 2006 From: jsierles at gmail.com (Joshua Sierles) Date: Wed, 20 Sep 2006 23:14:13 +0100 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution In-Reply-To: <1158780087.27841.24.camel@localhost.localdomain> References: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> <1158780087.27841.24.camel@localhost.localdomain> Message-ID: <722f07be0609201514h6d81825cu78209667128c9a83@mail.gmail.com> I have to chime in and agree with Zed here. We had similar problems at MOG, and came to the conclusion that solving the delegation problem is just curing the symptoms. By systematically offloading a lot of slow requests to background processes, we got more flexibility and the ability to check the progress of such events. I'd say the general consensus is that any page that needs more than a few seconds to load needs optimization or offloading. Joshua Sierles From ian at blenke.com Wed Sep 20 18:26:23 2006 From: ian at blenke.com (Ian C. Blenke) Date: Wed, 20 Sep 2006 18:26:23 -0400 Subject: [Mongrel] Spinning mongrels and SIGUSR1 Message-ID: <4511C00F.6070107@blenke.com> First off: Our clusters are LVS balanced Apache 2.2.3 + mod_proxy_balancer + gem mongrel 0.3.13.3 / mongrel_cluster 0.2 + memcached / gem memcache_client + gem rails 1.1.6 on debian boxen, and a pgcluster backend. On 2 of our deployed clusters, we are getting the "spinning mongrel" problem. As the clusters are very low volume right now, it takes days to collect a spinner, making it difficult to debug what the problem might be. From what I've been following on the list, the appropriate next debugging step is to send a SIGUSR1 signal to the spinning mongrel to get it to spit out what it thinks it is currently running. All we get from this is the following: /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:982:in `join': SIGUSR1 (SignalException) from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:982:in `join' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:982:in `join' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:136:in `run' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/command.rb:199:in `run' from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:235 from /usr/bin/mongrel_rails:18 And this is only when a mongrel responds to the SIGUSR1 signal. The same output everytime. About 10-20% of the time, a mongrel process won't respond to SIGUSR1, SIGHUP, or anything other than a SIGKILL. In either case, what should my next step be? The current plan is to run mongrel in debugging mode and beat the hell out of it, hoping to trigger the spinning response. After (during?) this, I guess I'll strace / gdb it to death. Any other suggestions? - Ian C. Blenke http://ian.blenke.com/ From ian at blenke.com Wed Sep 20 18:34:09 2006 From: ian at blenke.com (Ian C. Blenke) Date: Wed, 20 Sep 2006 18:34:09 -0400 Subject: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- QUERY_STRING Fixed In-Reply-To: <20060921.124850.78713392.rise@knavery.net> References: <1155772406.6122.11.camel@localhost.localdomain> <1155773674.6122.13.camel@localhost.localdomain> <20060921.124850.78713392.rise@knavery.net> Message-ID: <4511C1E1.7000305@blenke.com> Jonathan wrote: > I really gotta either get vmware or wine going for cross builds so I > >>can automate this. >> >> > >If it'd help I've got a VMware Workstation license sitting unused I'd >be happy to give you the key for. I'm not sure if the EULA >specifically allows or forbids this, but I know someone at the >director level over there and I'm comfortable with the ethics after a >few of the conversations we've had. Frankly for every version from 2 >on I've bought a license for a project, used it for a couple of months >maximum, and stuck it on the shelf. > > VMWare Player and VMWare Server are both "free" (as in beer if not libre), and there's always Fabrice Bellard's wonderful QEMU + kqemu. Anymore, the larger licensing issue is the underlying operating system you're building on, not the virtualization platform. Having fought to build cross build chains for win32 mozilla plugins under cygwin, you really just start to yearn for something native after a while. Also, the mozilla win32 tinderbox builds are seem to be running from virtual machines from what I can tell (I could very well be wrong). - Ian C. Blenke http://ian.blenke.com/ From anjan.bacchu at Summit.Fiserv.com Wed Sep 20 19:30:21 2006 From: anjan.bacchu at Summit.Fiserv.com (Bacchu, Anjan) Date: Wed, 20 Sep 2006 16:30:21 -0700 Subject: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- QUERY_STRING Fixed Message-ID: Hi Zed/Jonathan, VMWare Server is free now. http://www.vmware.com/products/server/ http://www.vmware.com/pdf/server_datasheet.pdf www.vmware.com/download/server Runs on any standard x86 hardware * Supports 64-bit guest operating systems, including Windows, Linux, and Solaris * Support for VMware VirtualCenter to efficiently manage infrastructure from a central management console * Experimental support for two-processor Virtual SMP(tm) * Experimental support for Intel(r) Virtualization Technology * Runs on a wider variety of Windows and Linux host and guest operating systems than any server virtualization product on the market * Support for any Windows or Linux application, including pre-built virtual appliances * Installs like an application, with quick and easy, wizard-driven installation * Quick and easy, wizard-driven virtual machine creation * Support for any VMware or Microsoft irtual machine format and Symantec LiveState Recovery images * Investment protection with easy upgrade path to VMware Infrastructure and other production-proven Vmware products * Virtual machine monitoring and management with an intuitive, user friendly remote console BR, ~A -----Original Message----- From: Jonathan [mailto:rise at knavery.net] Sent: Thursday, September 21, 2006 11:49 AM To: mongrel-users at rubyforge.org; zedshaw at zedshaw.com Subject: Re: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- QUERY_STRING Fixed On Wed, 16 Aug 2006 17:14:34 -0700 Zed Shaw wrote: > Correction, NOW the win32 gems are up. > I really gotta either get vmware or wine going for cross builds so I > can automate this. If it'd help I've got a VMware Workstation license sitting unused I'd be happy to give you the key for. I'm not sure if the EULA specifically allows or forbids this, but I know someone at the director level over there and I'm comfortable with the ethics after a few of the conversations we've had. Frankly for every version from 2 on I've bought a license for a project, used it for a couple of months maximum, and stuck it on the shelf. -- Jonathan Conway rise at knavery.net _______________________________________________ Mongrel-users mailing list Mongrel-users at rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users From msoulier at digitaltorque.ca Wed Sep 20 19:35:11 2006 From: msoulier at digitaltorque.ca (Michael P. Soulier) Date: Wed, 20 Sep 2006 19:35:11 -0400 Subject: [Mongrel] thank you Message-ID: <20060920233511.GS11663@tigger.digitaltorque.ca> I recently got into using RoR, and the only issue that concerned me was the apparently complexity of deployment. Setting up fastcgi can be a bit of a pain, and I was hoping that the Rails community would come up with something simpler. Mongrel was recommended to me from someone on my local Ruby user group. It was trivial to install as a Gem on my Linux desktop and the FreeBSD server that I am deploying on. It was trivial to supervise via Runit, to ensure high availability of the service. It was trivial to Proxy to from Apache. The site I'm working on is now run via mongrel through apache, trivial to set up. Thank you. Mike -- Michael P. Soulier "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060920/f2331152/attachment.bin From dselph at gmail.com Wed Sep 20 20:22:30 2006 From: dselph at gmail.com (Doug Selph) Date: Wed, 20 Sep 2006 19:22:30 -0500 Subject: [Mongrel] proxying and mongrel 0.3.13.4 Message-ID: I have been running a proxied mongrel-hosted app behind apache 2.0 (don't need clustering) for several months, and loving it. In that instance, I am proxying the root of the virtual host to mongrel. I am now in a situation where I need to proxy a directory name to mongrel for a new application, and not having any success. I saw Zed's mention of the --prefix option in 0.3.13.4, so I have updated to that release. Is this what should work? In httpd.conf: ProxyPass /thisapp http://localhost:7000/ ProxyPassReverse /thisapp http://localhost:7000/ Mongrel startup cmd: /usr/local/bin/mongrel_rails start -d --prefix=/thisapp -p 7000 -a 127.0.0.1 -l log/mongrel.log -P log/mongrel.pid -n 200 --user myuser --group mygroup With this setup, apache is logging a 404, but the 404 page being returned to the client looks to be mongrel's (simply says, "NOT FOUND"). Running `links http://localhost:7000/` from the colsole of the server gives me the default page for the rails app, so that piece is working. Am I just missing something that should be obvious? Thanks, Doug From snacktime at gmail.com Wed Sep 20 21:23:08 2006 From: snacktime at gmail.com (snacktime) Date: Wed, 20 Sep 2006 18:23:08 -0700 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution In-Reply-To: <722f07be0609201514h6d81825cu78209667128c9a83@mail.gmail.com> References: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> <1158780087.27841.24.camel@localhost.localdomain> <722f07be0609201514h6d81825cu78209667128c9a83@mail.gmail.com> Message-ID: <1f060c4c0609201823i7f55c0a6x599da64b61cd0105@mail.gmail.com> Might be interesting to give Perlbal (http://www.danga.com) a try as an http proxy. Looks extremely configurable and supports ssl. They also use an interesting technique where the backend node can return a reproxy command if it's busy, and the proxy can then send the request to another node. It also appears to be able to only send connections to nodes that are free to service a request. From zedshaw at zedshaw.com Wed Sep 20 22:22:26 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 20 Sep 2006 19:22:26 -0700 Subject: [Mongrel] Spinning mongrels and SIGUSR1 In-Reply-To: <4511C00F.6070107@blenke.com> References: <4511C00F.6070107@blenke.com> Message-ID: <1158805346.29131.13.camel@localhost.localdomain> On Wed, 2006-09-20 at 18:26 -0400, Ian C. Blenke wrote: > First off: Our clusters are LVS balanced Apache 2.2.3 + > mod_proxy_balancer + gem mongrel 0.3.13.3 / mongrel_cluster 0.2 + > memcached / gem memcache_client + gem rails 1.1.6 on debian boxen, and a > pgcluster backend. > > On 2 of our deployed clusters, we are getting the "spinning mongrel" > problem. As the clusters are very low volume right now, it takes days to > collect a spinner, making it difficult to debug what the problem might be. > > From what I've been following on the list, the appropriate next > debugging step is to send a SIGUSR1 signal to the spinning mongrel to > get it to spit out what it thinks it is currently running. USR2 is the debugging signal. You actually want to turn it on a few minutes after they start, and it's safe to turn on in production (not much of a performance hit). -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From zedshaw at zedshaw.com Wed Sep 20 22:23:50 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 20 Sep 2006 19:23:50 -0700 Subject: [Mongrel] thank you In-Reply-To: <20060920233511.GS11663@tigger.digitaltorque.ca> References: <20060920233511.GS11663@tigger.digitaltorque.ca> Message-ID: <1158805430.29131.15.camel@localhost.localdomain> On Wed, 2006-09-20 at 19:35 -0400, Michael P. Soulier wrote: > I recently got into using RoR, and the only issue that concerned me was the > apparently complexity of deployment. Setting up fastcgi can be a bit of a > pain, and I was hoping that the Rails community would come up with something > simpler. > > Mongrel was recommended to me from someone on my local Ruby user group. It was > trivial to install as a Gem on my Linux desktop and the FreeBSD server that I > am deploying on. It was trivial to supervise via Runit, to ensure high > availability of the service. It was trivial to Proxy to from Apache. > > The site I'm working on is now run via mongrel through apache, trivial to set > up. > > Thank you. That's what I like to hear. Awesome. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From luislavena at gmail.com Wed Sep 20 22:54:22 2006 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 20 Sep 2006 23:54:22 -0300 Subject: [Mongrel] [ANN] Mongrel 0.3.13.4 Pre-Release -- QUERY_STRING Fixed In-Reply-To: <20060921.124850.78713392.rise@knavery.net> References: <1155772406.6122.11.camel@localhost.localdomain> <1155773674.6122.13.camel@localhost.localdomain> <20060921.124850.78713392.rise@knavery.net> Message-ID: <71166b3b0609201954p65a89ef0md5cfa5a16912e7c8@mail.gmail.com> On 9/21/06, Jonathan wrote: > On Wed, 16 Aug 2006 17:14:34 -0700 Zed Shaw wrote: > > > Correction, NOW the win32 gems are up. > > > I really gotta either get vmware or wine going for cross builds so I > > can automate this. > > If it'd help I've got a VMware Workstation license sitting unused I'd > be happy to give you the key for. I'm not sure if the EULA > specifically allows or forbids this, but I know someone at the > director level over there and I'm comfortable with the ethics after a > few of the conversations we've had. Frankly for every version from 2 > on I've bought a license for a project, used it for a couple of months > maximum, and stuck it on the shelf. > I mailed Zed about doing a build bot automation farm, so each release on Linux, Windows or whatever other OS we decide to support could be automatically checked out and build, later sent result to mongrel-builds list. I was thinking on BuildBot (http://buildbot.sourceforge.net), a Python tool, but too complex for starters. Maybe Cerberus? (http://cerberus.rubyforge.org/) will be a better option? Anyway, I have a 1 Windows XP and 1 Windows 2000 unused licenses, or maybe I could build a Windows PE + VC2003 (which will run and reboot after 24hs running). That could be run inside VMWare Player or whatever. Ok, just an idea. > > -- > Jonathan Conway rise at knavery.net > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From zedshaw at zedshaw.com Wed Sep 20 23:50:52 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Wed, 20 Sep 2006 20:50:52 -0700 Subject: [Mongrel] proxying and mongrel 0.3.13.4 In-Reply-To: References: Message-ID: <1158810652.29131.18.camel@localhost.localdomain> On Wed, 2006-09-20 at 19:22 -0500, Doug Selph wrote: > I have been running a proxied mongrel-hosted app behind apache 2.0 > (don't need clustering) for several months, and loving it. In that > instance, I am proxying the root of the virtual host to mongrel. > > I am now in a situation where I need to proxy a directory name to > mongrel for a new application, and not having any success. I saw Zed's > mention of the --prefix option in 0.3.13.4, so I have updated to that > release. Run your mongrel with -B, hit it with a few requests, then go look at log/mongrel_debug/rails.log to see what is being passed to rails. Then look at mongrel.log (or the console) to see what request paths are coming in to mongrel from apache. It's most likely just the wrong paths coming from apache. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From matt at eastmedia.com Thu Sep 21 00:53:01 2006 From: matt at eastmedia.com (Matt Pelletier) Date: Thu, 21 Sep 2006 00:53:01 -0400 Subject: [Mongrel] How do you use Mongrel? Message-ID: Hey folks, I'm working on the Mongrel book with Zed, and wanted to get some feedback from the core users (this list) about how they use Mongrel. That sounds a bit vague, but I'm interested in hearing things about frustrating problems / workaround, preferred configurations, if you have a particular way you set up / store your config files when developing / deploying an app, for those of you running multiple handlers, if you have had to deal with any subtle issues, if there were any gotchas you encountered along the way from the docs that could be fixed (in the docs) or improved, any tricks you figured out along the way, etc. Any info will be credited properly. Thanks in advance. Matt =================== Matt Pelletier EastMedia t. 212-967-4239 f. 212-967-4257 m. 917-902-2525 w. www.eastmedia.com From jgeiger at gmail.com Thu Sep 21 09:31:41 2006 From: jgeiger at gmail.com (Joey Geiger) Date: Thu, 21 Sep 2006 08:31:41 -0500 Subject: [Mongrel] proxying and mongrel 0.3.13.4 In-Reply-To: <1158810652.29131.18.camel@localhost.localdomain> References: <1158810652.29131.18.camel@localhost.localdomain> Message-ID: <466af3440609210631j78fbd1a0mc0ca2a2c7dc598df@mail.gmail.com> >>In httpd.conf: >>ProxyPass /thisapp http://localhost:7000/ >>ProxyPassReverse /thisapp http://localhost:7000/ Needs to be In httpd.conf: ProxyPass /thisapp http://localhost:7000/thisapp ProxyPassReverse /thisapp http://localhost:7000/thisapp From al-mongrelusers at none.at Thu Sep 21 10:08:57 2006 From: al-mongrelusers at none.at (Alexander Lazic) Date: Thu, 21 Sep 2006 16:08:57 +0200 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution In-Reply-To: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> References: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> Message-ID: <20060921140857.GC2926@none.at> On Mit 20.09.2006 11:18, Paul Butcher wrote: >We have been searching for a Rails deployment architecture which works >for us for some time. We've recently moved from Apache 1.3 + FastCGI to >Apache 2.2 + mod_proxy_balancer + mongrel_cluster, and it's a >significant improvement. But it still exhibits serious performance >problems. Have you ever use haproxy http://haproxy.1wt.eu/ ?! He have the following feature which can help you: --- http://haproxy.1wt.eu/download/1.2/doc/haproxy-en.txt 3.4) Limiting the number of concurrent sessions on each server weight minconn maxconn --- This tool can also check the availibility of your backends. For ssl you need a ssl-termination SW such as stunnel or delegate or which ever SW you prefer. On the haproxy site you have a patch for stunnel for the x-forwarded-for header, if you need ;-) Regards Alex From mike at harmonypark.net Thu Sep 21 10:19:51 2006 From: mike at harmonypark.net (Mike Evans) Date: Thu, 21 Sep 2006 15:19:51 +0100 Subject: [Mongrel] File uploads intermittent upon first form submission Message-ID: I have Mongrel 0.3.13.4 running Rails 1.1.6 behind Apache 2.2.3 with mod_proxy_balancer, mongrel_cluster 0.2.0 as per the documentation, and mongrel_upload_progress 0.2, on Fedora Core 4. I'm using a cluster of three Mongrels. I have an existing app which allows users to upload files, and I'm migrating it to Mongrel from Lighttpd. Uploading files via multipart forms fails intermittently, using both my existing code and the mongrel_upload_progress example files/upload action. (My existing code doesn't reference anything to do with mongrel_upload_progress at all, so I don't think that's specifically at fault.) When it fails there is apparently no attempt to upload the file - the packets aren't being sent from my laptop and the form just sits there. A second submission of the form will work. Refresh the page, select the same file to upload, and maybe it will work first click, maybe not. Rinse and repeat. Small files less than 100kb seem to work first time, every time. Can anyone suggest an avenue of enquiry to try and work out what the problem might be? Cheers, Mike From krisleech at interkonect.com Thu Sep 21 10:27:40 2006 From: krisleech at interkonect.com (Kris Leech) Date: Thu, 21 Sep 2006 15:27:40 +0100 Subject: [Mongrel] Static files in public Message-ID: <4512A15C.6020402@interkonect.com> My question is about the static files in the Rails public folder. These files should be served by Apache instead of Mongrel, so do I need to upload these files to Apache's htdoc's or will Apache cache them the first time they are requested from Mongrel... Im not sure how this works? Many thanks. From carl.lerche at gmail.com Thu Sep 21 10:47:40 2006 From: carl.lerche at gmail.com (Carl Lerche) Date: Thu, 21 Sep 2006 07:47:40 -0700 Subject: [Mongrel] How do you use Mongrel? In-Reply-To: References: Message-ID: Well, right now I use mongrel for deploying my live rails apps. Pretty standard I guess. I've currently been using mongrel_cluster, but I would like to eventually use some kind of process monitoring (monit?). I have yet to really look into it though. The book really should cover how to use mongrel with capistrano since it seems to be the "standard" deployment method. I'm also working on an application that would require to track bandwidth sent out per user (members upload files and get x amount of MB of bandwidth a month). I'm thinking of writing a mongrel handler and doing it like that, but I'm not sure if that's the best way or not. -carl On 9/20/06, Matt Pelletier wrote: > Hey folks, > > I'm working on the Mongrel book with Zed, and wanted to get some > feedback from the core users (this list) about how they use Mongrel. > That sounds a bit vague, but I'm interested in hearing things about > frustrating problems / workaround, preferred configurations, if you > have a particular way you set up / store your config files when > developing / deploying an app, for those of you running multiple > handlers, if you have had to deal with any subtle issues, if there > were any gotchas you encountered along the way from the docs that > could be fixed (in the docs) or improved, any tricks you figured out > along the way, etc. Any info will be credited properly. > > Thanks in advance. > Matt > > =================== > Matt Pelletier > EastMedia > t. 212-967-4239 > f. 212-967-4257 > m. 917-902-2525 > w. www.eastmedia.com > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From carl.lerche at gmail.com Thu Sep 21 10:52:05 2006 From: carl.lerche at gmail.com (Carl Lerche) Date: Thu, 21 Sep 2006 07:52:05 -0700 Subject: [Mongrel] thank you In-Reply-To: <1158805430.29131.15.camel@localhost.localdomain> References: <20060920233511.GS11663@tigger.digitaltorque.ca> <1158805430.29131.15.camel@localhost.localdomain> Message-ID: You know, I'm going to add to this. I love mongrel. Simple, easy to use, flexible, etc... You're doing an amazing job with it :) So thanks! From mongrel at philip.pjkh.com Thu Sep 21 12:25:47 2006 From: mongrel at philip.pjkh.com (Philip Hallstrom) Date: Thu, 21 Sep 2006 11:25:47 -0500 (CDT) Subject: [Mongrel] How do you use Mongrel? In-Reply-To: References: Message-ID: <20060921112200.L96946@bravo.pjkh.com> > I'm working on the Mongrel book with Zed, and wanted to get some > feedback from the core users (this list) about how they use Mongrel. > That sounds a bit vague, but I'm interested in hearing things about > frustrating problems / workaround, preferred configurations, if you > have a particular way you set up / store your config files when > developing / deploying an app, for those of you running multiple > handlers, if you have had to deal with any subtle issues, if there > were any gotchas you encountered along the way from the docs that > could be fixed (in the docs) or improved, any tricks you figured out > along the way, etc. Any info will be credited properly. The only issue we've had is related to memcache connections not closing when you do a cluster:restart. See: http://rubyforge.org/tracker/index.php?func=detail&aid=5268&group_id=1306&atid=5145 Zed said this is a rails problem and I believe him. I imagine if I spent some time looking at it some more I'd figure out how to close the memcache connections within rails, but at the time we simply made the decision to hard restart mongrel (and apache) when necessary. Reason I mention this is the docs I was able to find about setting up memcache for use as fragment/session caching don't mention this as an issue, and it bit us... Actually I guess there is one other issue we've noticed... on a heavily hit server, restarting just mongrel, apache seems to take a little while to "find" it again. So we restart apache after restarting mongrel. Super minor issues all things considered :-) We were restarting lighttpd/fastcgi via cron, hourly... -philip From edv at hendrikstier.de Thu Sep 21 13:52:45 2006 From: edv at hendrikstier.de (Hendrik Stier) Date: Thu, 21 Sep 2006 19:52:45 +0200 Subject: [Mongrel] Static files in public In-Reply-To: <4512A15C.6020402@interkonect.com> References: <4512A15C.6020402@interkonect.com> Message-ID: <87EC44E0-5D4C-4830-88FF-1206F2DFFE3A@hendrikstier.de> Hi! Take a look at this document: http://mongrel.rubyforge.org/docs/ apache.html You should leave the static files in the public folder of your application, and configure Apache to use rewriting (see section "Configuring Apache2"). Regards, Hendrik Am 21.09.2006 um 16:27 schrieb Kris Leech: > My question is about the static files in the Rails public folder. > These > files should be served by Apache instead of Mongrel, so do I need to > upload these files to Apache's htdoc's or will Apache cache them the > first time they are requested from Mongrel... Im not sure how this > works? > > Many thanks. > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From g.vishnu at gmail.com Thu Sep 21 14:08:05 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Thu, 21 Sep 2006 23:38:05 +0530 Subject: [Mongrel] How do you use Mongrel? In-Reply-To: References: Message-ID: Hey, We use the following elements for our deployment: 1. A hardware load balancer with two servers as backends, each running: 2. One lighttpd instance, routed to a pound acting as a load balancer, each with: 3. Two mongrel instances. 4. A monit process on each server monitoring pound, lighty & mongrel. 5. A separate database server with monit running on that too. In addition, adding Capistrano's cap stop and start_mongrel_cluster magic scripts to the way we deploy. Mongrel's been amazing. Vish On 9/21/06, Carl Lerche wrote: > > Well, right now I use mongrel for deploying my live rails apps. Pretty > standard I guess. I've currently been using mongrel_cluster, but I > would like to eventually use some kind of process monitoring (monit?). > I have yet to really look into it though. The book really should cover > how to use mongrel with capistrano since it seems to be the "standard" > deployment method. I'm also working on an application that would > require to track bandwidth sent out per user (members upload files and > get x amount of MB of bandwidth a month). I'm thinking of writing a > mongrel handler and doing it like that, but I'm not sure if that's the > best way or not. > > -carl > > On 9/20/06, Matt Pelletier wrote: > > Hey folks, > > > > I'm working on the Mongrel book with Zed, and wanted to get some > > feedback from the core users (this list) about how they use Mongrel. > > That sounds a bit vague, but I'm interested in hearing things about > > frustrating problems / workaround, preferred configurations, if you > > have a particular way you set up / store your config files when > > developing / deploying an app, for those of you running multiple > > handlers, if you have had to deal with any subtle issues, if there > > were any gotchas you encountered along the way from the docs that > > could be fixed (in the docs) or improved, any tricks you figured out > > along the way, etc. Any info will be credited properly. > > > > Thanks in advance. > > Matt > > > > =================== > > Matt Pelletier > > EastMedia > > t. 212-967-4239 > > f. 212-967-4257 > > m. 917-902-2525 > > w. www.eastmedia.com > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060921/26a06b8c/attachment-0001.html From mongrel at philip.pjkh.com Thu Sep 21 14:15:51 2006 From: mongrel at philip.pjkh.com (Philip Hallstrom) Date: Thu, 21 Sep 2006 13:15:51 -0500 (CDT) Subject: [Mongrel] Static files in public In-Reply-To: <4512A15C.6020402@interkonect.com> References: <4512A15C.6020402@interkonect.com> Message-ID: <20060921131424.S99615@bravo.pjkh.com> > My question is about the static files in the Rails public folder. These > files should be served by Apache instead of Mongrel, so do I need to > upload these files to Apache's htdoc's or will Apache cache them the > first time they are requested from Mongrel... Im not sure how this works? Apache won't cache them unless you tell it to. I think most people point Apache to RAILS_ENV/public and configure things so that Apache only passes on requests to mongrel that it can't find in the filesystem... http://mongrel.rubyforge.org/docs/apache.html (configuring apache2 section) -philip From wyhaines at gmail.com Thu Sep 21 14:14:42 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Thu, 21 Sep 2006 12:14:42 -0600 Subject: [Mongrel] How do you use Mongrel? In-Reply-To: References: Message-ID: On 9/20/06, Matt Pelletier wrote: > I'm working on the Mongrel book with Zed, and wanted to get some > feedback from the core users (this list) about how they use Mongrel. > That sounds a bit vague, but I'm interested in hearing things about > frustrating problems / workaround, preferred configurations, if you > have a particular way you set up / store your config files when > developing / deploying an app, for those of you running multiple > handlers, if you have had to deal with any subtle issues, if there > were any gotchas you encountered along the way from the docs that > could be fixed (in the docs) or improved, any tricks you figured out > along the way, etc. Any info will be credited properly. I have just recently (in the last two weeks) put working Mongrel support into IOWA, and I as well as some users are already using it as a deployment platform for sites and apps even though I've not done a new production release with the support, yet. I am also using the trie classifier library in one of the dispatchers that I am bundling with IOWA (dispatchers in IOWA are modular, so one can pick from a few in the distribtution, or just plug in something custom to do what one needs). Performance is comparable to using apache2 with the mod_ruby handler for communication, and is close to fcgi performance, but configuration and testing is much simpler, so it is a definite win for me. Kirk Haines From gethemant at gmail.com Thu Sep 21 14:58:33 2006 From: gethemant at gmail.com (hemant) Date: Fri, 22 Sep 2006 00:28:33 +0530 Subject: [Mongrel] Static files in public In-Reply-To: <4512A15C.6020402@interkonect.com> References: <4512A15C.6020402@interkonect.com> Message-ID: On 9/21/06, Kris Leech wrote: > My question is about the static files in the Rails public folder. These > files should be served by Apache instead of Mongrel, so do I need to > upload these files to Apache's htdoc's or will Apache cache them the > first time they are requested from Mongrel... Im not sure how this works? > > Many > Please search through the mailing list. Someone explained nicely, how rewrite rules that you probably copied from mongrel page...searches for the existence of a file....it it finds the requested file...well apache serves it..otherwise it assumes, a dynamic request and forwards it to mongrel. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From paul at paulbutcher.com Thu Sep 21 15:06:30 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Thu, 21 Sep 2006 20:06:30 +0100 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn'twork for us and the beginning of a solution In-Reply-To: <20060921140857.GC2926@none.at> Message-ID: <000c01c6ddb1$0c0ff4c0$7301a8c0@paullaptop> > Have you ever use haproxy http://haproxy.1wt.eu/ ?! In a word, no :-) > He have the following feature which can help you: Thanks - sounds interesting. We'll give it a go! -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From gethemant at gmail.com Thu Sep 21 15:17:42 2006 From: gethemant at gmail.com (hemant) Date: Fri, 22 Sep 2006 00:47:42 +0530 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn't work for us and the beginning of a solution In-Reply-To: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> References: <001e01c6dc9e$2c8f7360$5f01a8c0@paullaptop> Message-ID: On 9/20/06, Paul Butcher wrote: > > The real solution to the problem would be to remove Rails' inability to > handle more than one thread. In the absence of that solution, however, we've > implemented (in Ruby) what might be the world's smallest load-balancer. It > only ever sends a single request to each member of the cluster at a time. > It's called HighWire and is available on RubyForge (no Gem yet - it's on the > list of things to do!): > > svn checkout svn://rubyforge.org/var/svn/highwire > > Using this instead of mod_proxy_balancer, and running the same test script > above, we see approximately 54 fast and 6 slow requests per minute. > > HighWire is very young and has a way to go. It's not had any serious > optimization or testing, and there are a bunch of things that need doing > before it can really be considered production ready. But it does work for > us, and does produce a significant performance improvement. > > Please check it out and let us know what you think. (*Laziness kicks in*) How do you find...which one of mongrel id idle? -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From zedshaw at zedshaw.com Thu Sep 21 17:26:18 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Thu, 21 Sep 2006 14:26:18 -0700 Subject: [Mongrel] Spinning mongrels and SIGUSR1 In-Reply-To: <1158805346.29131.13.camel@localhost.localdomain> References: <4511C00F.6070107@blenke.com> <1158805346.29131.13.camel@localhost.localdomain> Message-ID: <1158873978.6027.9.camel@localhost.localdomain> On Wed, 2006-09-20 at 19:22 -0700, Zed Shaw wrote: > On Wed, 2006-09-20 at 18:26 -0400, Ian C. Blenke wrote: > > First off: Our clusters are LVS balanced Apache 2.2.3 + > > mod_proxy_balancer + gem mongrel 0.3.13.3 / mongrel_cluster 0.2 + > > memcached / gem memcache_client + gem rails 1.1.6 on debian boxen, and a > > pgcluster backend. > > > > On 2 of our deployed clusters, we are getting the "spinning mongrel" > > problem. As the clusters are very low volume right now, it takes days to > > collect a spinner, making it difficult to debug what the problem might be. > > > > From what I've been following on the list, the appropriate next > > debugging step is to send a SIGUSR1 signal to the spinning mongrel to > > get it to spit out what it thinks it is currently running. > > USR2 is the debugging signal. You actually want to turn it on a few > minutes after they start, and it's safe to turn on in production (not > much of a performance hit). > I'm such an idiot. It is USR1. You've got the 0.3.13.3 version of mongrel, so you need to upgrade if you want to get the USR1 debugging. Sorry. Zed From steven at lumos.us Thu Sep 21 18:12:52 2006 From: steven at lumos.us (Steven Lumos) Date: Thu, 21 Sep 2006 15:12:52 -0700 Subject: [Mongrel] Spinning mongrels and SIGUSR1 References: <4511C00F.6070107@blenke.com> <1158805346.29131.13.camel@localhost.localdomain> Message-ID: <86k63wx40r.fsf@bitty.lumos.us> Zed Shaw writes: > On Wed, 2006-09-20 at 18:26 -0400, Ian C. Blenke wrote: >> First off: Our clusters are LVS balanced Apache 2.2.3 + >> mod_proxy_balancer + gem mongrel 0.3.13.3 / mongrel_cluster 0.2 + >> memcached / gem memcache_client + gem rails 1.1.6 on debian boxen, and a >> pgcluster backend. >> >> On 2 of our deployed clusters, we are getting the "spinning mongrel" >> problem. As the clusters are very low volume right now, it takes days to >> collect a spinner, making it difficult to debug what the problem might be. >> >> From what I've been following on the list, the appropriate next >> debugging step is to send a SIGUSR1 signal to the spinning mongrel to >> get it to spit out what it thinks it is currently running. > > USR2 is the debugging signal. You actually want to turn it on a few > minutes after they start, and it's safe to turn on in production (not > much of a performance hit). Uh, USR2 is "restart", right? At least that's what Mongrel claims when it starts up. Steve From steven at lumos.us Thu Sep 21 18:16:17 2006 From: steven at lumos.us (Steven Lumos) Date: Thu, 21 Sep 2006 15:16:17 -0700 Subject: [Mongrel] Sync and Mutex compatible? Message-ID: <86ac4sx3v2.fsf@bitty.lumos.us> With Mongrel using Sync, are there any potential problems with actions that start threads and use Mutex? Steve From _ at whats-your.name Thu Sep 21 19:09:28 2006 From: _ at whats-your.name (carmen) Date: Thu, 21 Sep 2006 23:09:28 +0000 Subject: [Mongrel] thank you In-Reply-To: References: <20060920233511.GS11663@tigger.digitaltorque.ca> <1158805430.29131.15.camel@localhost.localdomain> Message-ID: <20060921230928.GA12184@replic.net> On Thu Sep 21, 2006 at 07:52:05AM -0700, Carl Lerche wrote: > You know, I'm going to add to this. I love mongrel. Simple, easy to > use, flexible, etc... You're doing an amazing job with it :) mongrel is so easy to use, i dont even know im using it. actually removed all traces of webrick from /usr/lib/ruby and uninstalled lighttpd just to make sure. i'm not positive, but im prettty sure mongrel is my seeing eye dog when camping in the yard, fetching tent poles and scaring away indians with his ugly mug... > > So thanks! > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From ian at blenke.com Thu Sep 21 20:57:16 2006 From: ian at blenke.com (Ian C. Blenke) Date: Thu, 21 Sep 2006 20:57:16 -0400 Subject: [Mongrel] Mongrel spinning on read_multipart Message-ID: <451334EC.6010003@blenke.com> On Zed's suggestion, I caught two new spinning mongrels and sent a SIGUSR2. The code appears to be stuck in read_multipart for both processes: # kill -USR2 6109 ** USR2 signal received. Thu Sep 21 14:55:39 EDT 2006: Reaping 1 threads for slow workers because of 'shutdown' Thread # is too old, killing. Waiting for 1 requests to finish, could take 60 seconds.Error calling Dispatcher.dispatch # /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:600:in `loop' /usr/lib/ruby/1.8/cgi.rb:984:in `read_multipart' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/cgi_ext/raw_post_data_fix.rb:20:in `initialize_query' /usr/lib/ruby/1.8/cgi.rb:2270:in `initialize' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/cgi.rb:47:in `initialize' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/rails.rb:67:in `process' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:551:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:550:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:636:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:636:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:625:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:956:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:955:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:127:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/command.rb:199:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:235 /usr/bin/mongrel_rails:18 The same for process 6100. We've had multipart problems before, but most of those were due to malformed multipart MIME posts. Has anyone else experienced multipart mime posts causing mongrel to spin out of control? - Ian C. Blenke http://ian.blenke.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ian.vcf Type: text/x-vcard Size: 117 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060921/c8d42e05/attachment.vcf From bassnode at gmail.com Thu Sep 21 22:29:21 2006 From: bassnode at gmail.com (Ed Hickey) Date: Thu, 21 Sep 2006 21:29:21 -0500 Subject: [Mongrel] How do you use Mongrel? In-Reply-To: References: Message-ID: <733f56120609211929v47d94c44x733abad22bcb30bd@mail.gmail.com> Vishnu, I'm curious to why you're using lighttpd and pound instead of just pound? I don't know much about either so the answer might be obvious. ed On 9/21/06, Vishnu Gopal wrote: > > Hey, > > We use the following elements for our deployment: > > 1. A hardware load balancer with two servers as backends, each running: > 2. One lighttpd instance, routed to a pound acting as a load balancer, > each with: > 3. Two mongrel instances. > 4. A monit process on each server monitoring pound, lighty & mongrel. > 5. A separate database server with monit running on that too. > > In addition, adding Capistrano's cap stop and start_mongrel_cluster magic > scripts to the way we deploy. > > Mongrel's been amazing. > Vish > > On 9/21/06, Carl Lerche wrote: > > > > Well, right now I use mongrel for deploying my live rails apps. Pretty > > standard I guess. I've currently been using mongrel_cluster, but I > > would like to eventually use some kind of process monitoring (monit?). > > I have yet to really look into it though. The book really should cover > > how to use mongrel with capistrano since it seems to be the "standard" > > deployment method. I'm also working on an application that would > > require to track bandwidth sent out per user (members upload files and > > get x amount of MB of bandwidth a month). I'm thinking of writing a > > mongrel handler and doing it like that, but I'm not sure if that's the > > best way or not. > > > > -carl > > > > On 9/20/06, Matt Pelletier < matt at eastmedia.com> wrote: > > > Hey folks, > > > > > > I'm working on the Mongrel book with Zed, and wanted to get some > > > feedback from the core users (this list) about how they use Mongrel. > > > That sounds a bit vague, but I'm interested in hearing things about > > > frustrating problems / workaround, preferred configurations, if you > > > have a particular way you set up / store your config files when > > > developing / deploying an app, for those of you running multiple > > > handlers, if you have had to deal with any subtle issues, if there > > > were any gotchas you encountered along the way from the docs that > > > could be fixed (in the docs) or improved, any tricks you figured out > > > along the way, etc. Any info will be credited properly. > > > > > > Thanks in advance. > > > Matt > > > > > > =================== > > > Matt Pelletier > > > EastMedia > > > t. 212-967-4239 > > > f. 212-967-4257 > > > m. 917-902-2525 > > > w. www.eastmedia.com > > > > > > > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > -- Ed Hickey Developer Litmus Media 816-533-0409 ehickey at litmusmedia.com A Member of Think Partnership, Inc www.ThinkPartnership.com Amex ticker symbol: THK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060921/3e494ab1/attachment-0001.html From bassnode at gmail.com Thu Sep 21 22:45:09 2006 From: bassnode at gmail.com (Ed Hickey) Date: Thu, 21 Sep 2006 21:45:09 -0500 Subject: [Mongrel] How do you use Mongrel? In-Reply-To: <20060921112200.L96946@bravo.pjkh.com> References: <20060921112200.L96946@bravo.pjkh.com> Message-ID: <733f56120609211945s2cba0818s76998dea87f209f0@mail.gmail.com> On 9/21/06, Philip Hallstrom wrote: > > > I'm working on the Mongrel book with Zed, and wanted to get some > > feedback from the core users (this list) about how they use Mongrel. > > That sounds a bit vague, but I'm interested in hearing things about > > frustrating problems / workaround, preferred configurations... We're not doing anything too unique, but: 3 web servers and w/ a DB cluster on the backend: -F5 load balancer in front of 2 of the web servers (no software balancer) -the third server is running Apache as a balancer -each server has10 mongrels running one small problem i ran into the first time i installed mogrel was that i didn't have gcc installed on the machine. mongrel installed without error, but when i tried to start it, i got cryptic errors (well, at least they were cryptic to me). after some googling i found out it was because of the missing complier so maybe that could be checked upon gem installation? ...or at least in the Readme (which it may well be by now). we're having some other intermittent speeds issues, but i believe it's a DB/Rails problem and can't blame mongrel. we're in beta and consistently serving a couple requests per second all day long without real issue. not bad indeed. i have another setup with nginx balancing 10 mongrels, but that's too new to really comment on it much. regarding docs - there wasn't any when i first installed mongrel. about the only thing i could find (of much substance) was a howto on some blog...seemed to work well enough. Zed's new docs look very helpful though. i'll try to supply some more useful info as our applications progress and we run into more obstacles. ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060921/d28f0c63/attachment.html From ian at blenke.com Fri Sep 22 01:01:47 2006 From: ian at blenke.com (Ian C. Blenke) Date: Fri, 22 Sep 2006 01:01:47 -0400 Subject: [Mongrel] Mongrel spinning on read_multipart In-Reply-To: <451334EC.6010003@blenke.com> References: <451334EC.6010003@blenke.com> Message-ID: <45136E3B.5010009@blenke.com> This is a repost, apparently my earlier message attempts were eaten by rubyforge. On Zed's suggestion, I caught two new spinning mongrels and sent a SIGUSR2 (yeah, not a SIGUSR1, 0.3.13.3 and all). The code appears to be stuck in read_multipart for both processes: # kill -USR2 6109 ** USR2 signal received. Thu Sep 21 14:55:39 EDT 2006: Reaping 1 threads for slow workers because of 'shutdown' Thread # is too old, killing. Waiting for 1 requests to finish, could take 60 seconds.Error calling Dispatcher.dispatch # /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:600:in `loop' /usr/lib/ruby/1.8/cgi.rb:984:in `read_multipart' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/cgi_ext/raw_post_data_fix.rb:20:in `initialize_query' /usr/lib/ruby/1.8/cgi.rb:2270:in `initialize' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/cgi.rb:47:in `initialize' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/rails.rb:67:in `process' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:551:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:550:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:636:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:636:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:625:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:956:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:955:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:127:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/command.rb:199:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:235 /usr/bin/mongrel_rails:18 The same for process 6100. We've had multipart problems before, but most of those were due to malformed multipart MIME posts. Has anyone else experienced multipart mime posts causing mongrel to spin out of control? - Ian C. Blenke http://ian.blenke.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ian.vcf Type: text/x-vcard Size: 117 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060922/53f5558b/attachment.vcf From wyhaines at gmail.com Fri Sep 22 01:12:10 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Thu, 21 Sep 2006 23:12:10 -0600 Subject: [Mongrel] Sync and Mutex compatible? In-Reply-To: <86ac4sx3v2.fsf@bitty.lumos.us> References: <86ac4sx3v2.fsf@bitty.lumos.us> Message-ID: On 9/21/06, Steven Lumos wrote: > > With Mongrel using Sync, are there any potential problems with actions > that start threads and use Mutex? No. They are separate locking primitives. The fundamental algoritm is the same between Sync (for exclusive locks) and Mutex, with regard to locking, so they are pretty comparable there, though Sync ends up doing a lot more work to get the same thing done, and I think there may be potential for a race condition in Sync's locking because of it. I could be wrong there, too, though. I've not delved into that investigation with any depth. In unlocking, the two differ fairly significantly. Mutex pulls a single waiting thread out of the queue of waiting threads and wakes it up. Sync wakes every waiting thread and lets them all vie for the lock. Sync's approach means that when there are a lot of waiting threads, unlocking is a lot slower with Sync. It also probably doesn't matter as the first threads that wake up are the ones most likely to acquire the lock anyway, so that's probably why Mutex doesn't do it that way. Other than those basic differences, though, they are completely compatible so long as you don't expect a Mutex synchronize block and a Sync synchronize block to have any effect on the other. Kirk Haines From al-mongrelusers at none.at Fri Sep 22 01:30:42 2006 From: al-mongrelusers at none.at (Alexander Lazic) Date: Fri, 22 Sep 2006 07:30:42 +0200 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn'twork for us and the beginning of a solution In-Reply-To: <000c01c6ddb1$0c0ff4c0$7301a8c0@paullaptop> References: <20060921140857.GC2926@none.at> <000c01c6ddb1$0c0ff4c0$7301a8c0@paullaptop> Message-ID: <20060922053042.GA23783@none.at> On Don 21.09.2006 20:06, Paul Butcher wrote: >> Have you ever use haproxy http://haproxy.1wt.eu/ ?! > >In a word, no :-) > >> He have the following feature which can help you: > >Thanks - sounds interesting. We'll give it a go! Please let us/me know your experience ;-) Thanks && Regards Alex From zedshaw at zedshaw.com Fri Sep 22 03:54:48 2006 From: zedshaw at zedshaw.com (Zed Shaw) Date: Fri, 22 Sep 2006 00:54:48 -0700 Subject: [Mongrel] Mongrel spinning on read_multipart In-Reply-To: <451334EC.6010003@blenke.com> References: <451334EC.6010003@blenke.com> Message-ID: <1158911688.5805.13.camel@localhost.localdomain> On Thu, 2006-09-21 at 20:57 -0400, Ian C. Blenke wrote: > On Zed's suggestion, I caught two new spinning mongrels and sent a > SIGUSR2. The code appears to be stuck in read_multipart for both processes: Hey Ian, can you give me some more information on this? 1) What is being uploaded and what are the average sizes and content types? 2) Does the process stay pegged for a long time (like never ends) or is it possible that the mime processing is just taking longer than you expect? 3) How often does this happen? 4) Operating system particulars, and Ruby version. Thanks. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From krisleech at interkonect.com Fri Sep 22 04:22:49 2006 From: krisleech at interkonect.com (Kris Leech) Date: Fri, 22 Sep 2006 09:22:49 +0100 Subject: [Mongrel] Static files in public In-Reply-To: <4512A15C.6020402@interkonect.com> References: <4512A15C.6020402@interkonect.com> Message-ID: <45139D59.1040109@interkonect.com> Thanks for the replies, I have read the apache page in the mongrel docs already, I guess I didnt explain too well, but what I do get is that if Apache and Mongrel are on the same physical machine that you can set Apache's DocumentRoot to the public folder and it would look there for static files first. But if Apache and Mongrel are on different machines Apache does not have access to the files in public... I hope that makes my question a bit clearer? Many thanks. From paul at paulbutcher.com Fri Sep 22 04:51:54 2006 From: paul at paulbutcher.com (Paul Butcher) Date: Fri, 22 Sep 2006 09:51:54 +0100 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn'twork for us and the beginning of a solution In-Reply-To: Message-ID: <009101c6de24$5ab1d2b0$0202fea9@paullaptop> > (*Laziness kicks in*) How do you find...which one of mongrel id idle? It's a fantastically subtle and complicated algorithm. Not. The main thread handles incoming connections, and then there's one thread per worker. The main thread does this: while request = server.accept queue.push request end And each worker does this: loop do request = queue.pop # Handle the request ... end -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher LinkedIn: https://www.linkedin.com/in/paulbutcher From g.vishnu at gmail.com Fri Sep 22 05:41:21 2006 From: g.vishnu at gmail.com (Vishnu Gopal) Date: Fri, 22 Sep 2006 15:11:21 +0530 Subject: [Mongrel] How do you use Mongrel? In-Reply-To: <733f56120609211945s2cba0818s76998dea87f209f0@mail.gmail.com> References: <20060921112200.L96946@bravo.pjkh.com> <733f56120609211945s2cba0818s76998dea87f209f0@mail.gmail.com> Message-ID: Hey Ed, On 9/22/06, Ed Hickey wrote: > > [..]-each server has10 mongrels running > [..] > One quick question: What's the configuration of the servers you are running on? Thanks! Vishnu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060922/80b1410b/attachment.html From wyhaines at gmail.com Fri Sep 22 09:34:14 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Fri, 22 Sep 2006 07:34:14 -0600 Subject: [Mongrel] How do you use Mongrel? In-Reply-To: <733f56120609211945s2cba0818s76998dea87f209f0@mail.gmail.com> References: <20060921112200.L96946@bravo.pjkh.com> <733f56120609211945s2cba0818s76998dea87f209f0@mail.gmail.com> Message-ID: On 9/21/06, Ed Hickey wrote: > We're not doing anything too unique, but: > > 3 web servers and w/ a DB cluster on the backend: > -F5 load balancer in front of 2 of the web servers (no software balancer) > -the third server is running Apache as a balancer > -each server has10 mongrels running > > we're having some other intermittent speeds issues, but i believe it's a > DB/Rails problem and can't blame mongrel. we're in beta and consistently > serving a couple requests per second all day long without real issue. not > bad indeed. Is your application _really_ computation intensive? It boggles my mind that something running 3 web servers (single processor boxes?) with a separate db cluster (2 servers?) and 30 processes to handle it all could be having intermittent speed issues while serving only a couple requests per second. Kirk Haines From bassnode at gmail.com Fri Sep 22 10:27:53 2006 From: bassnode at gmail.com (Ed Hickey) Date: Fri, 22 Sep 2006 09:27:53 -0500 Subject: [Mongrel] How do you use Mongrel? In-Reply-To: References: <20060921112200.L96946@bravo.pjkh.com> <733f56120609211945s2cba0818s76998dea87f209f0@mail.gmail.com> Message-ID: <733f56120609220727x1d0eefb4r18a9b2d85a5b182b@mail.gmail.com> The deal is that it's 1 Rails app that encompasses all the facets of an web advertising system (similar to Google's Adwords). There are 3 different 'faces'. One serves ads in XML, one is an admin box and one handles clicks, exclusively. The 3 boxes aren't connected in anyway other than the database cluster. Do we actually _need_ 10 mongrels running on each box? I can't really say yet. We are expecting it to be quite a traffic-heavy system so we're preparing... That said, we're still in beta and testing the limits. I can say that the 10 mongrels aren't weighing the servers down at all. The only thing that gets a little (memory) hungry are the Mysql processes which is what I think could be part of our intermittant speed problem. Sometimes they spiral up to 40MB a piece...and spawn into 30 different processes. We are using MySQL clustering (which is new to us) and it behaves much differently than standard MyISAM/InnoDB tables so we're still sorting that out. I'm curious as to what you mean when when you say "all could be having intermittent speed issues while serving only a couple requests per second.". Were you assuming all the servers were clustered together? If not, how could they be having speed issues? Any input would be helpful. ed On 9/22/06, Kirk Haines wrote: > > On 9/21/06, Ed Hickey wrote: > > > We're not doing anything too unique, but: > > > > 3 web servers and w/ a DB cluster on the backend: > > -F5 load balancer in front of 2 of the web servers (no software > balancer) > > -the third server is running Apache as a balancer > > -each server has10 mongrels running > > > > Is your application _really_ computation intensive? It boggles my > mind that something running 3 web servers (single processor boxes?) > with a separate db cluster (2 servers?) and 30 processes to handle it > all could be having intermittent speed issues while serving only a > couple requests per second. Kirk Haines > -- Ed Hickey Developer Litmus Media 816-533-0409 ehickey at litmusmedia.com A Member of Think Partnership, Inc www.ThinkPartnership.com Amex ticker symbol: THK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060922/64b5e08a/attachment-0001.html From bassnode at gmail.com Fri Sep 22 10:52:41 2006 From: bassnode at gmail.com (Ed Hickey) Date: Fri, 22 Sep 2006 09:52:41 -0500 Subject: [Mongrel] How do you use Mongrel? In-Reply-To: References: <20060921112200.L96946@bravo.pjkh.com> <733f56120609211945s2cba0818s76998dea87f209f0@mail.gmail.com> Message-ID: <733f56120609220752p196866b5yca9c1ab954b4c598@mail.gmail.com> On 9/22/06, Vishnu Gopal wrote: > > Hey Ed, > > On 9/22/06, Ed Hickey wrote: > > > > [..]-each server has10 mongrels running > > [..] > > > > One quick question: What's the configuration of the servers you are > running on? > > Thanks! > Vishnu > Vishnu, The servers are Dual 2.8Ghz Xeons w/ 2GB RAM CentOS 3.6 (64bit) MySQL 5.0 (NDBCluster) Rais 1.16 Mongrel 0.3.13.4 Apache 2.2 (only on web frontend box) Apache is setup with mod_proxy so we can serve static content on the admin box. The other 2 boxes only serve XML and/or forward requests, so they are fronted by the F5 load balancers. All 3 boxes operate independently. They talk via the DB. I'm not sure that answers your question...? -- ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060922/7bcdc5c0/attachment.html From ian at blenke.com Fri Sep 22 13:04:39 2006 From: ian at blenke.com (Ian C. Blenke) Date: Fri, 22 Sep 2006 13:04:39 -0400 Subject: [Mongrel] Mongrel spinning on read_multipart In-Reply-To: <1158911688.5805.13.camel@localhost.localdomain> References: <451334EC.6010003@blenke.com> <1158911688.5805.13.camel@localhost.localdomain> Message-ID: <451417A7.1020402@blenke.com> Zed Shaw wrote: > On Thu, 2006-09-21 at 20:57 -0400, Ian C. Blenke wrote: > >> On Zed's suggestion, I caught two new spinning mongrels and sent a >> SIGUSR2. The code appears to be stuck in read_multipart for both processes: >> > > Hey Ian, can you give me some more information on this? > > 1) What is being uploaded and what are the average sizes and content > types? > XML encapsulated HTML pages from various public websites. Browser extensions are uploading the pages to a Rails server using a RESTful JSON based multi-part MIME API post. Some are pretty large, most are fairly small. > 2) Does the process stay pegged for a long time (like never ends) or is > it possible that the mime processing is just taking longer than you > expect? > The processes stay pegged for a long time, they never seem to end. > 3) How often does this happen? > During the early development cycle of the browser extensions, this was a huge problem, as the developers were sending malformed multi-part MIME boundaries. Regardless of the size of the submitted webpage, mongrel would go into a tight spin. After giving each developer a local VMWare player runtime with the entire application environment to beat up against, they cleaned up their bugs and the problem "went away". Today, we're only getting this problem occasionally. On a low volume site, a couple times a day. It "feels like" the extensions are getting interrupted midway through their posts to the server (TCP streams reset, etc), but I haven't verified this conclusively yet. > 4) Operating system particulars, and Ruby version. > Multicore AMD64X2 4G whitebox servers, a Debian woody based homegrown distro with many many backports (virtually sarge), linux 2.6.13 kernel. backported Ruby 1.8.4 (-1, not the newer buggier builds). Rails 1.1.6 (from gems). - Ian C. Blenke http://ian.blenke.com/ From ian at blenke.com Fri Sep 22 13:18:37 2006 From: ian at blenke.com (Ian C. Blenke) Date: Fri, 22 Sep 2006 13:18:37 -0400 Subject: [Mongrel] Static files in public In-Reply-To: <45139D59.1040109@interkonect.com> References: <4512A15C.6020402@interkonect.com> <45139D59.1040109@interkonect.com> Message-ID: <45141AED.3040505@blenke.com> Kris Leech wrote: > Thanks for the replies, I have read the apache page in the mongrel docs > already, I guess I didnt explain too well, but what I do get is that if > Apache and Mongrel are on the same physical machine that you can set > Apache's DocumentRoot to the public folder and it would look there for > static files first. But if Apache and Mongrel are on different machines > Apache does not have access to the files in public... > > I hope that makes my question a bit clearer? > The easiest way is to define an "asset_host": config.action_controller.asset_host = "http://assets.example.com" Look at your "config/environments/production.rb" file, you should see that line in there. When rails helpers generate links to static content, the above asset_host is used in the URLs. Browsers would then go to your asset server cluster to get that static content. The "other" way to address this would be to have a "reverse proxy" tier in front of your web tier and rails tier that would use something like mod_rewrite rules to shunt content to the appropriate cluster. If the static files are more difficult to identify than simply grouping the content directories (/images/, /javascript/, /stylesheets/), that would mean adding a new RewriteRule everytime you add some static content, unless the "reverse proxy" tier has a local reference copy to use to know where to shunt the request. On the other hand, if your reverse proxy tier already has an rsynced copy of the public folder static content, and can serve that static content directly, it is arguable why you wouldn't simply host the static content off of your reverse proxy tier directly. This is what many folks appear to be doing with apache 2.2 and mod_proxy_balancer right now. - Ian C. Blenke http://ian.blenke.com/ From me at seebq.com Sun Sep 24 20:36:40 2006 From: me at seebq.com (Charles Brian Quinn) Date: Sun, 24 Sep 2006 20:36:40 -0400 Subject: [Mongrel] [PATCH] documentation additions for Apache Message-ID: <3a2de0cd0609241736t11587037u222227194929b0f0@mail.gmail.com> I added some stuff for the new pre-release with prefix for serving multiple rails apps, and did some in general updates/maintenance to the apache page. Please if anyone wants to add anything, or have any suggestions, , or if you've got some clever apache rules / tools / configs -- let me know, or feel free to pull it down and patch yourself. And also let me know if I've missed any attributions! cheers, -- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com -------------- next part -------------- A non-text attachment was scrubbed... Name: apache.page.diff Type: application/octet-stream Size: 6800 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060924/4573f930/attachment.obj From msoulier at digitaltorque.ca Sun Sep 24 21:20:31 2006 From: msoulier at digitaltorque.ca (Michael P. Soulier) Date: Sun, 24 Sep 2006 21:20:31 -0400 Subject: [Mongrel] hosting multiple apps Message-ID: <20060925012030.GC23414@tigger.digitaltorque.ca> I am considering creating a web interface for system administration, but it would need a plug-in architecture, adding new UIs as new services are added. I'm thinking about doing this with multiple Rails applications, and I'm curious as to whether mongrel can most multiple apps in a single instance, as opposed to running one for each. Is this possible? Thanks, Mike -- Michael P. Soulier "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060924/975e8d1b/attachment.bin From zedshaw at zedshaw.com Sun Sep 24 23:24:14 2006 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Sun, 24 Sep 2006 20:24:14 -0700 Subject: [Mongrel] hosting multiple apps In-Reply-To: <20060925012030.GC23414@tigger.digitaltorque.ca> References: <20060925012030.GC23414@tigger.digitaltorque.ca> Message-ID: <20060924202414.0e3d2fc2.zedshaw@zedshaw.com> On Sun, 24 Sep 2006 21:20:31 -0400 "Michael P. Soulier" wrote: > I am considering creating a web interface for system administration, but it > would need a plug-in architecture, adding new UIs as new services are added. > I'm thinking about doing this with multiple Rails applications, and I'm > curious as to whether mongrel can most multiple apps in a single instance, as > opposed to running one for each. Is this possible? At around 23M minimum for each Rails application you'd never win. Take a look at how webmin does it. They basically have a high level API over their little plugins that is similar to CGI. It all runs inside a perl webserver that's kind of like Mongrel. What you probably also want to check out is the gem_plugins gem that comes with Mongrel. It lets you create plugins like this with users just having to install a gem. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From _ at whats-your.name Sun Sep 24 23:33:42 2006 From: _ at whats-your.name (carmen) Date: Mon, 25 Sep 2006 03:33:42 +0000 Subject: [Mongrel] hosting multiple apps In-Reply-To: <20060925012030.GC23414@tigger.digitaltorque.ca> References: <20060925012030.GC23414@tigger.digitaltorque.ca> Message-ID: <20060925033342.GA29602@replic.net> On Sun Sep 24, 2006 at 09:20:31PM -0400, Michael P. Soulier wrote: > I am considering creating a web interface for system administration, but it > would need a plug-in architecture, adding new UIs as new services are added. > I'm thinking about doing this with multiple Rails applications, and I'm > curious as to whether mongrel can most multiple apps in a single instance, as > opposed to running one for each. Is this possible? this is developing. you can already run multiple camping apps (and maybe iowa/nitro/etc?). multiple rails apps wll require usage of the sandbox.. > > Thanks, > Mike > -- > Michael P. Soulier > "Any intelligent fool can make things bigger and more complex... It > takes a touch of genius - and a lot of courage to move in the opposite > direction." --Albert Einstein > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From snacktime at gmail.com Mon Sep 25 02:07:01 2006 From: snacktime at gmail.com (snacktime) Date: Sun, 24 Sep 2006 23:07:01 -0700 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn'twork for us and the beginning of a solution In-Reply-To: <009101c6de24$5ab1d2b0$0202fea9@paullaptop> References: <009101c6de24$5ab1d2b0$0202fea9@paullaptop> Message-ID: <1f060c4c0609242307w3e22380bte316dc94f3289ade@mail.gmail.com> I was taking a look at the source for mod_proxy_balancer this evening, and it looks like the simplest solution to this whole problem is to just add another balance method. The functions that determine what balance member gets the next request are pretty short. I'm a pretty bad C programmer, but I subscribed to the apache-dev list this evening and maybe I can get someone there to assist me on the finer points. >From what I saw, it looks like you could keep an array of balance members that are handling a request, and then implement a short wait cycle if all the members are busy. Have it write out a warning to the apache log when it has to wait so you know when to be adding more mongrels. I'll let everyone know how it goes. Chris From massimo at zero.it Mon Sep 25 02:50:07 2006 From: massimo at zero.it (Massimo Santoli) Date: Mon, 25 Sep 2006 08:50:07 +0200 Subject: [Mongrel] mongrel.pid disappearing Message-ID: <45177C1F.9020909@zero.it> Hi to everybody, This my first post on the list. I'm a newby of mongrel & rails, I've deployed my first project and everything seems to work fine, the only problem I have is the following: After about 1 or 2 days of the mongrel_rails daemon running the mongrel.pid in the log directory disappears, the mongrel process is still there running but doesn't respond anymore. I have a very simple configuration an Apache webserver configured as proxy-pass to the mongrel ( single process ) daemon answering on port 8080. Its a demo project thus the traffic is practically 0. Any hints? Thanks, Massimo From jacob at jacobatzen.dk Mon Sep 25 05:03:00 2006 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Mon, 25 Sep 2006 11:03:00 +0200 Subject: [Mongrel] mongrel.pid disappearing In-Reply-To: <45177C1F.9020909@zero.it> References: <45177C1F.9020909@zero.it> Message-ID: <20060925090300.GA14511@nezbo.dhcp.aub.dk> On Mon, Sep 25, 2006 at 08:50:07AM +0200, Massimo Santoli wrote: > Hi to everybody, > > This my first post on the list. > I'm a newby of mongrel & rails, I've deployed my first project and > everything seems to work fine, the only problem I have is the following: > After about 1 or 2 days of the mongrel_rails daemon running the > mongrel.pid in the log directory disappears, the mongrel process is > still there running > but doesn't respond anymore. > I have a very simple configuration an Apache webserver configured as > proxy-pass to the mongrel ( single process ) daemon answering on port 8080. > Its a demo project thus the traffic is practically 0. Which operating system are you using? Does mongrel.log show anything? -- Cheers, - Jacob Atzen From zedshaw at zedshaw.com Mon Sep 25 05:19:01 2006 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Mon, 25 Sep 2006 02:19:01 -0700 Subject: [Mongrel] mongrel.pid disappearing In-Reply-To: <45177C1F.9020909@zero.it> References: <45177C1F.9020909@zero.it> Message-ID: <20060925021901.007e7836.zedshaw@zedshaw.com> On Mon, 25 Sep 2006 08:50:07 +0200 Massimo Santoli wrote: > Hi to everybody, > > This my first post on the list. > I'm a newby of mongrel & rails, I've deployed my first project and > everything seems to work fine, the only problem I have is the following: > After about 1 or 2 days of the mongrel_rails daemon running the > mongrel.pid in the log directory disappears, the mongrel process is > still there running > but doesn't respond anymore. > I have a very simple configuration an Apache webserver configured as > proxy-pass to the mongrel ( single process ) daemon answering on port 8080. > Its a demo project thus the traffic is practically 0. Hi Massimo, first thing I'd think of is that you have some sort of build process that clears the log directory. Are you running a rake task that does this, or running capistrano and it's doing this? I vaguely remember something like rake clear_logs doing this. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From al-mongrelusers at none.at Mon Sep 25 07:55:27 2006 From: al-mongrelusers at none.at (Alexander Lazic) Date: Mon, 25 Sep 2006 13:55:27 +0200 Subject: [Mongrel] Why Rails + mongrel_cluster + load balancing doesn'twork for us and the beginning of a solution In-Reply-To: <1f060c4c0609242307w3e22380bte316dc94f3289ade@mail.gmail.com> References: <009101c6de24$5ab1d2b0$0202fea9@paullaptop> <1f060c4c0609242307w3e22380bte316dc94f3289ade@mail.gmail.com> Message-ID: <20060925115527.GA6674@none.at> On Son 24.09.2006 23:07, snacktime wrote: > >I was taking a look at the source for mod_proxy_balancer this evening, >and it looks like the simplest solution to this whole problem is to >just add another balance method. The functions that determine what >balance member gets the next request are pretty short. I'm a pretty >bad C programmer, but I subscribed to the apache-dev list this evening >and maybe I can get someone there to assist me on the finer points. I think it would be possible to use this setup: +------------------------+ |apache_mod_proxy_balance| | or any other webserver | +------------------------+ | V +----------------------------+ | haproxy maxconn 1 minconn 1| +----------------------------+ | | V V +-------------+ +-------------+ |mongrel_rails| |mongrel_rails| +-------------+ +-------------+ thoughts?! Pros: haproxy balance thru all mongel_rails check the backend if still alive it queues the incomming requests Cons: more complex setup you need to manage more programms/tools Regards Aleks From msoulier at digitaltorque.ca Mon Sep 25 09:34:57 2006 From: msoulier at digitaltorque.ca (Michael P. Soulier) Date: Mon, 25 Sep 2006 09:34:57 -0400 Subject: [Mongrel] hosting multiple apps In-Reply-To: <20060924202414.0e3d2fc2.zedshaw@zedshaw.com> References: <20060925012030.GC23414@tigger.digitaltorque.ca> <20060924202414.0e3d2fc2.zedshaw@zedshaw.com> Message-ID: <20060925133457.GM23414@tigger.digitaltorque.ca> On 24/09/06 Zed A. Shaw said: > At around 23M minimum for each Rails application you'd never win. Take a > look at how webmin does it. They basically have a high level API over their > little plugins that is similar to CGI. It all runs inside a perl webserver > that's kind of like Mongrel. > > What you probably also want to check out is the gem_plugins gem that comes > with Mongrel. It lets you create plugins like this with users just having > to install a gem. Good info, thanks. Mike -- Michael P. Soulier "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060925/f6255f1c/attachment.bin From me at seebq.com Mon Sep 25 10:48:03 2006 From: me at seebq.com (Charles Brian Quinn) Date: Mon, 25 Sep 2006 10:48:03 -0400 Subject: [Mongrel] mongrel.pid disappearing In-Reply-To: <20060925021901.007e7836.zedshaw@zedshaw.com> References: <45177C1F.9020909@zero.it> <20060925021901.007e7836.zedshaw@zedshaw.com> Message-ID: <3a2de0cd0609250748x39d99d1ct778f9e10f2f7faad@mail.gmail.com> I had a problem once with logrotation (the logrotate daemon) not being very friendly to lightty and the fcgis - killing 'em and not restarting after clearing their logs. Hope that helps, On 9/25/06, Zed A. Shaw wrote: > On Mon, 25 Sep 2006 08:50:07 +0200 > Massimo Santoli wrote: > > > Hi to everybody, > > > > This my first post on the list. > > I'm a newby of mongrel & rails, I've deployed my first project and > > everything seems to work fine, the only problem I have is the following: > > After about 1 or 2 days of the mongrel_rails daemon running the > > mongrel.pid in the log directory disappears, the mongrel process is > > still there running > > but doesn't respond anymore. > > I have a very simple configuration an Apache webserver configured as > > proxy-pass to the mongrel ( single process ) daemon answering on port 8080. > > Its a demo project thus the traffic is practically 0. > > Hi Massimo, first thing I'd think of is that you have some sort of build process that clears the log directory. Are you running a rake task that does this, or running capistrano and it's doing this? I vaguely remember something like rake clear_logs doing this. > > -- > Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com From massimo at zero.it Mon Sep 25 11:59:08 2006 From: massimo at zero.it (Massimo Santoli) Date: Mon, 25 Sep 2006 17:59:08 +0200 Subject: [Mongrel] mongrel.pid disappearing In-Reply-To: <20060925021901.007e7836.zedshaw@zedshaw.com> References: <45177C1F.9020909@zero.it> <20060925021901.007e7836.zedshaw@zedshaw.com> Message-ID: <4517FCCC.9040208@zero.it> Zed, It seems that the issues is fixed. I'll explain better again: The missing mongrel.pid file problem was reported by the mongrel_rails mongrel::stop command when I noticed that the the mongrel server stop responding and I was trying to stop it, actually sometimes the pid file was there but the mongrel stop command reported that the file was missing. Again I noticed this problem because my configuration ( apache 2.0.59 + mod_proxy + 1 mongrel task ) stopped respoding after a couple of hours it had been launched, also contacting directly the mongrel server didn't work. Looking around various thread I've found for a similar problem : mongrel stopping responding, due to a bug in apache 2.2.x and it could be solved by adding: SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1 I've modified the server configuration and now it's over 8 hours that the server is running fine. Hope this solved the problem I'll let you know and if you want I can try to reproduce the bug. Massimo Zed A. Shaw wrote: >On Mon, 25 Sep 2006 08:50:07 +0200 >Massimo Santoli wrote: > > > >>Hi to everybody, >> >>This my first post on the list. >>I'm a newby of mongrel & rails, I've deployed my first project and >>everything seems to work fine, the only problem I have is the following: >>After about 1 or 2 days of the mongrel_rails daemon running the >>mongrel.pid in the log directory disappears, the mongrel process is >>still there running >>but doesn't respond anymore. >>I have a very simple configuration an Apache webserver configured as >>proxy-pass to the mongrel ( single process ) daemon answering on port 8080. >>Its a demo project thus the traffic is practically 0. >> >> > >Hi Massimo, first thing I'd think of is that you have some sort of build process that clears the log directory. Are you running a rake task that does this, or running capistrano and it's doing this? I vaguely remember something like rake clear_logs doing this. > > > From krisleech at interkonect.com Mon Sep 25 12:48:23 2006 From: krisleech at interkonect.com (Kris Leech) Date: Mon, 25 Sep 2006 17:48:23 +0100 Subject: [Mongrel] HTTP Parser (Regal) Message-ID: <45180857.9080804@interkonect.com> Hi I was interested to see how Mongrel uses Lex/Yacc to parse the HTTP requests using a Regal generated parser. I downloaded the source but do not see the lex and yacc files... From jan.svitok at gmail.com Mon Sep 25 17:18:00 2006 From: jan.svitok at gmail.com (Jan Svitok) Date: Mon, 25 Sep 2006 23:18:00 +0200 Subject: [Mongrel] HTTP Parser (Regal) In-Reply-To: <45180857.9080804@interkonect.com> References: <45180857.9080804@interkonect.com> Message-ID: <8d9b3d920609251417y1b08eb12p7d75c6dd33d46923@mail.gmail.com> On 9/25/06, Kris Leech wrote: > Hi I was interested to see how Mongrel uses Lex/Yacc to parse the HTTP > requests using a Regal generated parser. I downloaded the source but do > not see the lex and yacc files... > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >From former thread "Mongrel grammar file": > The Ragel grammar is ext/http11/http11_parser.rl It seems that there's no lex/yacc involved. Ragel is a replacement of lex/yacc, if I understood it properly. From mrueckert at suse.de Mon Sep 25 18:52:02 2006 From: mrueckert at suse.de (Marcus Rueckert) Date: Tue, 26 Sep 2006 00:52:02 +0200 Subject: [Mongrel] HTTP Parser (Regal) In-Reply-To: <45180857.9080804@interkonect.com> References: <45180857.9080804@interkonect.com> Message-ID: <20060925225202.GZ30353@suse.de> On 2006-09-25 17:48:23 +0100, Kris Leech wrote: > Hi I was interested to see how Mongrel uses Lex/Yacc to parse the HTTP > requests using a Regal generated parser. I downloaded the source but > do not see the lex and yacc files... as you wrote yourself mongrel is using ragel for its parser. ragel does not use lex/yacc at all. http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/ext/http11/?root=mongrel http11_parser.c and http11_parser.rl are your friends. and of course the ragel documentation at http://www.cs.queensu.ca/home/thurston/ragel/. hope this helps darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From zedshaw at zedshaw.com Mon Sep 25 18:55:21 2006 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Mon, 25 Sep 2006 15:55:21 -0700 Subject: [Mongrel] HTTP Parser (Regal) In-Reply-To: <45180857.9080804@interkonect.com> References: <45180857.9080804@interkonect.com> Message-ID: <20060925155521.340125d4.zedshaw@zedshaw.com> On Mon, 25 Sep 2006 17:48:23 +0100 Kris Leech wrote: > Hi I was interested to see how Mongrel uses Lex/Yacc to parse the HTTP > requests using a Regal generated parser. I downloaded the source but do > not see the lex and yacc files... > No lex and yacc used, just Ragel. Look for the .rl file and google for Ragel. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From scarydog at mac.com Tue Sep 26 01:08:33 2006 From: scarydog at mac.com (Nathan Donaldson) Date: Tue, 26 Sep 2006 17:08:33 +1200 Subject: [Mongrel] Interesting proxy problem In-Reply-To: References: Message-ID: Kia ora all, I have been working on migrating our FastCGI sites to Mongrel over the past couple of weeks and have come up against an interesting problem. We have it setup so that Apache 2.0 is proxying requests to Balance which is configured to use a mongrel cluster. This works well *except* it won't serve javascripts, which causes pages to hang. We've run balance in debug mode with packetdump and it looks as though the file is being sent. But the browser is left waiting for a response. The interesting thing is; it sometime works the very first time when the cluster has been restarted. Has anyone got any ideas what I can try next? Regards Nathan From massimo at zero.it Tue Sep 26 03:16:05 2006 From: massimo at zero.it (Massimo Santoli) Date: Tue, 26 Sep 2006 09:16:05 +0200 Subject: [Mongrel] mongrel.pid disappearing In-Reply-To: <20060925164800.Y83564@bravo.pjkh.com> References: <45177C1F.9020909@zero.it> <20060925021901.007e7836.zedshaw@zedshaw.com> <4517FCCC.9040208@zero.it> <20060925164800.Y83564@bravo.pjkh.com> Message-ID: <4518D3B5.4090202@zero.it> Unfortunately this morning the mongrel server was hung up ( mongrel.pid was there ). Here is a snapshot from the log: ############################# Processing Base#index (for 212.121.66.93 at 2006-09-26 09:11:00) [GET] Session ID: 0fb84c71774cad2aada0404f9b42e0f9 Parameters: {} Mongrel::TimeoutError (Mongrel timed out this thread: shutdown): /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:637:in `write' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/vendor/mysql.rb:517:in `write' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/vendor/mysql.rb:491:in `command' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/vendor/mysql.rb:223:in `close' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/mysql_adapter.rb:168:in `disconnect! ' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/mysql_adapter.rb:163:in `reconnect!' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/abstract_adapter.rb:85:in `verify!' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/abstract/connection_specification.rb :99:in `verify_active_connections!' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/abstract/connection_specification.rb :98:in `verify_active_connections!' /usr/local/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispatcher.rb:70:in `prepare_application' /usr/local/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispatcher.rb:37:in `dispatch' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/rails.rb:84:in `process' /usr/local/lib/ruby/1.8/sync.rb:229:in `synchronize' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/rails.rb:83:in `process' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:580:in `process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:579:in `process_client' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:686:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:673:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:267:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:266:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:127:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/command.rb:211:in `run' /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:231 /usr/local/bin/mongrel_rails:18 ######################## Is there some kind of problem on the mysql connection? Any hints welcomed. Thanks, Massimo From zedshaw at zedshaw.com Tue Sep 26 03:35:05 2006 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 26 Sep 2006 00:35:05 -0700 Subject: [Mongrel] Interesting proxy problem In-Reply-To: References: Message-ID: <20060926003505.22625726.zedshaw@zedshaw.com> On Tue, 26 Sep 2006 17:08:33 +1200 Nathan Donaldson wrote: > Kia ora all, > > I have been working on migrating our FastCGI sites to Mongrel over > the past couple of weeks and have come up against an interesting > problem. > > We have it setup so that Apache 2.0 is proxying requests to Balance > which is configured to use a mongrel cluster. > Most of the instructions are for Apache 2.2.x since it supports the newer mod_proxy_balancer. Is there an operational reason why you can't use that? > This works well *except* it won't serve javascripts, which causes > pages to hang. We've run balance in debug mode with packetdump and it > looks as though the file is being sent. But the browser is left > waiting for a response. What version of Mongrel? -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From krisleech at interkonect.com Tue Sep 26 03:49:09 2006 From: krisleech at interkonect.com (Kris Leech) Date: Tue, 26 Sep 2006 08:49:09 +0100 Subject: [Mongrel] HTTP Parser (Regal) In-Reply-To: <45180857.9080804@interkonect.com> References: <45180857.9080804@interkonect.com> Message-ID: <4518DB75.6080000@interkonect.com> Kris Leech wrote: >Hi I was interested to see how Mongrel uses Lex/Yacc to parse the HTTP >requests using a Regal generated parser. I downloaded the source but do >not see the lex and yacc files... > > Thanks for the replies... I see, my mistake, Regal is a replacement for Lex/Yacc, Im guessing it is very similar just a different implementation for the same concept of grammer and parser? Do you mind me asking what made you choose Regal over Lex/Yacc? >_______________________________________________ >Mongrel-users mailing list >Mongrel-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > From dee.zsombor at gmail.com Tue Sep 26 08:33:57 2006 From: dee.zsombor at gmail.com (Dee Zsombor) Date: Tue, 26 Sep 2006 15:33:57 +0300 Subject: [Mongrel] mongrel.pid disappearing In-Reply-To: <4518D3B5.4090202@zero.it> References: <45177C1F.9020909@zero.it> <20060925021901.007e7836.zedshaw@zedshaw.com> <4517FCCC.9040208@zero.it> <20060925164800.Y83564@bravo.pjkh.com> <4518D3B5.4090202@zero.it> Message-ID: <45191E35.9020904@gmail.com> Dont know if this is related but you might want to install the mysql gem, and use the native driver instead of the ruby one. $sudo gem install mysql Should be faster too. Zsombor -- Company - http://primalgrasp.com Thoughts - http://deezsombor.blogspot.com From mongrel_users at homerlex.mailshell.com Tue Sep 26 08:50:37 2006 From: mongrel_users at homerlex.mailshell.com (mongrel_users at homerlex.mailshell.com) Date: Tue, 26 Sep 2006 05:50:37 -0700 Subject: [Mongrel] Mongrel Processes Dying Message-ID: <1159275037.4519221d32903@www.mailshell.com> We are seeing mongrel processes dying in our mongrel cluster. What is the best way to troubleshoot this? We have ruby 1.8.4, Rails 1.1.0 (upgrading soon), MySql 4.1 running on Red Hat Enterprise Linux ES release 4, Apache 2.2, mongrel-0.3.13.3, mongrel_cluster-0.2.0 I saw the following messages in the mongrel.log but not sure if theay are related to the processes dying. It would be nice if the log had date/time for each entry! /usr/local/lib/ruby/1.8/net/http.rb:562: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i686-linux] /usr/local/lib/ruby/1.8/net/http.rb:562: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i686-linux] /usr/local/lib/ruby/1.8/net/http.rb:562: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i686-linux] Any help is greatly appreciated _______________________________________________________ The FREE service that prevents junk email http://www.mailshell.com From mongrel_users at homerlex.mailshell.com Tue Sep 26 08:51:42 2006 From: mongrel_users at homerlex.mailshell.com (mongrel_users at homerlex.mailshell.com) Date: Tue, 26 Sep 2006 05:51:42 -0700 Subject: [Mongrel] Clustering - Avoiding "dead" processes? Message-ID: <1159275102.4519225e72d2c@www.mailshell.com> I have Mongrel Cluster setup with Apache a mod_proxy_balancer. I've seen (from time to time) mongrel instances become non-responsive. Is there anyway to configure the balancer so that it "knows" which processes are no longer good and stops trying to use them? _______________________________________________________ The FREE service that prevents junk email http://www.mailshell.com From massimo at zero.it Tue Sep 26 10:16:28 2006 From: massimo at zero.it (Massimo Santoli) Date: Tue, 26 Sep 2006 16:16:28 +0200 Subject: [Mongrel] mongrel.pid disappearing In-Reply-To: <45191E35.9020904@gmail.com> References: <45177C1F.9020909@zero.it> <20060925021901.007e7836.zedshaw@zedshaw.com> <4517FCCC.9040208@zero.it> <20060925164800.Y83564@bravo.pjkh.com> <4518D3B5.4090202@zero.it> <45191E35.9020904@gmail.com> Message-ID: <4519363C.3070602@zero.it> Thanks for the hint. I'll try immediately, Massimo Dee Zsombor wrote: >Dont know if this is related but you might want to install the mysql gem, >and use the native driver instead of the ruby one. > >$sudo gem install mysql > >Should be faster too. > >Zsombor > > From zedshaw at zedshaw.com Tue Sep 26 10:31:36 2006 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 26 Sep 2006 07:31:36 -0700 Subject: [Mongrel] HTTP Parser (Regal) In-Reply-To: <4518DB75.6080000@interkonect.com> References: <45180857.9080804@interkonect.com> <4518DB75.6080000@interkonect.com> Message-ID: <20060926073136.c6bffaea.zedshaw@zedshaw.com> On Tue, 26 Sep 2006 08:49:09 +0100 Kris Leech wrote: > Kris Leech wrote: > > >Hi I was interested to see how Mongrel uses Lex/Yacc to parse the HTTP > >requests using a Regal generated parser. I downloaded the source but do > >not see the lex and yacc files... > > > > > Thanks for the replies... > > I see, my mistake, Regal is a replacement for Lex/Yacc, Im guessing it > is very similar just a different implementation for the same concept of > grammer and parser? > Do you mind me asking what made you choose Regal over Lex/Yacc? I wouldn't say it "replaces" yacc (I like lemon myself). I'd consider it like lex + 1/2 of yacc or a super fantastic insane lex. It's still using the regex algorithms that lex does, it just gives you a lot more control and power in a nicer syntax. If you wanted to parse a full language you'd probably still want to use a LL or LR parser generator. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From eimorton at gmail.com Tue Sep 26 10:32:20 2006 From: eimorton at gmail.com (Erik Morton) Date: Tue, 26 Sep 2006 10:32:20 -0400 Subject: [Mongrel] Clustering - Avoiding "dead" processes? In-Reply-To: <1159275102.4519225e72d2c@www.mailshell.com> References: <1159275102.4519225e72d2c@www.mailshell.com> Message-ID: <4CE72B5A-F52A-4299-94EC-B166A3425AEF@gmail.com> I have a very similar stack to you and I noticed Mongrels dying once or twice a day. Now I'm using Monit to watch each individual Mongrel in the cluster and I've noticed that each Mongrel gets restarted once a day on average. I haven't got around to figure out the exact cause yet, but with Monit there is always a full cluster available. Erik On Sep 26, 2006, at 8:51 AM, mongrel_users at homerlex.mailshell.com wrote: > I have Mongrel Cluster setup with Apache a mod_proxy_balancer. > I've seen (from time to time) mongrel instances become non- > responsive. Is there anyway to configure the balancer so that it > "knows" which processes are no longer good and stops trying to use > them? > > _______________________________________________________ > The FREE service that prevents junk email http://www.mailshell.com > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From zedshaw at zedshaw.com Tue Sep 26 10:34:53 2006 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 26 Sep 2006 07:34:53 -0700 Subject: [Mongrel] Mongrel Processes Dying In-Reply-To: <1159275037.4519221d32903@www.mailshell.com> References: <1159275037.4519221d32903@www.mailshell.com> Message-ID: <20060926073453.bbb1b186.zedshaw@zedshaw.com> On Tue, 26 Sep 2006 05:50:37 -0700 mongrel_users at homerlex.mailshell.com wrote: > We are seeing mongrel processes dying in our mongrel cluster. What is the best way to > troubleshoot this? > > We have ruby 1.8.4, Rails 1.1.0 (upgrading soon), MySql 4.1 running on Red Hat Enterprise Linux > ES release 4, Apache 2.2, mongrel-0.3.13.3, mongrel_cluster-0.2.0 > > I saw the following messages in the mongrel.log but not sure if theay are related to the > processes dying. It would be nice if the log had date/time for each entry! > > /usr/local/lib/ruby/1.8/net/http.rb:562: [BUG] Segmentation fault > ruby 1.8.4 (2005-12-24) [i686-linux] These are segmentation faults inside Ruby's http code. Not sure how you're getting those but you'll need to investigate how your system is apparently totally different from everyone else's. For example, why is it in /usr/local? I'm thinking maybe you're mixing ruby installations/versions. And, it's really hard to change http.rb to produce timestamps during a segfault. Actually the fact that ruby is giving you a line number is pretty magical, so be thankful. Normally you'd have to gdb a core file for that. Which brings up another thing, turn on core dumps and that might help track it down. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From wyhaines at gmail.com Tue Sep 26 10:38:44 2006 From: wyhaines at gmail.com (Kirk Haines) Date: Tue, 26 Sep 2006 08:38:44 -0600 Subject: [Mongrel] Mongrel Processes Dying In-Reply-To: <1159275037.4519221d32903@www.mailshell.com> References: <1159275037.4519221d32903@www.mailshell.com> Message-ID: On 9/26/06, mongrel_users at homerlex.mailshell.com > We have ruby 1.8.4, Rails 1.1.0 (upgrading soon), MySql 4.1 running on Red Hat Enterprise Linux > ES release 4, Apache 2.2, mongrel-0.3.13.3, mongrel_cluster-0.2.0 > > I saw the following messages in the mongrel.log but not sure if theay are related to the > processes dying. It would be nice if the log had date/time for each entry! > > /usr/local/lib/ruby/1.8/net/http.rb:562: [BUG] Segmentation fault > ruby 1.8.4 (2005-12-24) [i686-linux] Segmentation faults are bad. That said, those segfaults are at this line: s = timeout(@open_timeout) { TCPSocket.open(conn_address(), conn_port()) } Which is curious. I don't know where, in your version of Mongrel, that would be called. I've crawled all through the Mongrel source, and the only places that I see Net::HTTP usage are in the tests. Kirk Haines From zedshaw at zedshaw.com Tue Sep 26 13:35:33 2006 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 26 Sep 2006 10:35:33 -0700 Subject: [Mongrel] Clustering - Avoiding "dead" processes? In-Reply-To: <4CE72B5A-F52A-4299-94EC-B166A3425AEF@gmail.com> References: <1159275102.4519225e72d2c@www.mailshell.com> <4CE72B5A-F52A-4299-94EC-B166A3425AEF@gmail.com> Message-ID: <20060926103533.552dac72.zedshaw@zedshaw.com> On Tue, 26 Sep 2006 10:32:20 -0400 Erik Morton wrote: > I have a very similar stack to you and I noticed Mongrels dying once > or twice a day. Now I'm using Monit to watch each individual Mongrel > in the cluster and I've noticed that each Mongrel gets restarted once > a day on average. I haven't got around to figure out the exact cause > yet, but with Monit there is always a full cluster available. > Can you turn on CPU usage monitoring with Monit and tell me if Monit has to restart mongrel due to CPU usage? Thanks. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From Daniel.Berger at qwest.com Tue Sep 26 14:08:10 2006 From: Daniel.Berger at qwest.com (Daniel Berger) Date: Tue, 26 Sep 2006 12:08:10 -0600 Subject: [Mongrel] Mongrel Processes Dying In-Reply-To: <20060926073453.bbb1b186.zedshaw@zedshaw.com> References: <1159275037.4519221d32903@www.mailshell.com> <20060926073453.bbb1b186.zedshaw@zedshaw.com> Message-ID: <45196C8A.6040502@qwest.com> Zed A. Shaw wrote: > On Tue, 26 Sep 2006 05:50:37 -0700 > mongrel_users at homerlex.mailshell.com wrote: > >> We are seeing mongrel processes dying in our mongrel cluster. What is the best way to >> troubleshoot this? >> >> We have ruby 1.8.4, Rails 1.1.0 (upgrading soon), MySql 4.1 running on Red Hat Enterprise Linux >> ES release 4, Apache 2.2, mongrel-0.3.13.3, mongrel_cluster-0.2.0 >> >> I saw the following messages in the mongrel.log but not sure if theay are related to the >> processes dying. It would be nice if the log had date/time for each entry! >> >> /usr/local/lib/ruby/1.8/net/http.rb:562: [BUG] Segmentation fault >> ruby 1.8.4 (2005-12-24) [i686-linux] > > These are segmentation faults inside Ruby's http code. Not sure how you're getting those but you'll need to investigate how your system is apparently totally different from everyone else's. For example, why is it in /usr/local? I'm thinking maybe you're mixing ruby installations/versions. > > And, it's really hard to change http.rb to produce timestamps during a segfault. Actually the fact that ruby is giving you a line number is pretty magical, so be thankful. Normally you'd have to gdb a core file for that. > > Which brings up another thing, turn on core dumps and that might help track it down. > I did notice that there were some fixes for http.rb in the ChangeLog for 1.8.5. I don't know if upgrading is an option, but you may want to consider it. Mind you, given that the problem ultimately seems to be coming from TCPSocket, I'm not sure if they'll help. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From one.three at gmail.com Tue Sep 26 15:03:40 2006 From: one.three at gmail.com (13) Date: Tue, 26 Sep 2006 22:03:40 +0300 Subject: [Mongrel] Expert feedback needed Message-ID: <2f3066870609261203r7630c552p9ab8a1724a79527a@mail.gmail.com> Hello list, Some time ago I was looking for apache (as non balanced proxy) + mongrel configurations. Almost everybody seemed to use similar approaches (one of these could be found @ mongrel.rubygorge.org docs) with mod_rewrite. I don't use proxy_balancer because I don't need it at the moment (my site has pretty low traffic). This is apache configuration that I'm using at the moment. It's tested as Zed suggested (mr start -e production -B) and it looks like all static files are served by apache and dynamic ones be mongrel. Here is my apache config: ServerName myapp.tld ServerAlias www.myapp.tld DocumentRoot /var/www/sites/myapp/current/public Options FollowSymLinks AllowOverride None Order allow,deny Allow from all RewriteEngine On # Check for maintenance file. Let apache load it if it exists RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f RewriteRule . /system/maintenance.html [L] # Let apache serve static files RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f RewriteRule (.*) $1 [L] # Don't do forward proxying ProxyRequests Off # Enable reverse proxying Order deny,allow Allow from all # Pass other requests to mongrel instance ProxyPass / http://127.0.0.1:8200/ ProxyPassReverse / http://127.0.0.1:8200/ It would be great if some expert could take a look at my config and point me at my mistakes etc ! I am asking this because it looks like it just works, and it makes me think that it can't be so easy :) Thanks, Martins From eimorton at gmail.com Tue Sep 26 15:40:00 2006 From: eimorton at gmail.com (Erik Morton) Date: Tue, 26 Sep 2006 15:40:00 -0400 Subject: [Mongrel] Clustering - Avoiding "dead" processes? In-Reply-To: <20060926103533.552dac72.zedshaw@zedshaw.com> References: <1159275102.4519225e72d2c@www.mailshell.com> <4CE72B5A-F52A-4299-94EC-B166A3425AEF@gmail.com> <20060926103533.552dac72.zedshaw@zedshaw.com> Message-ID: <55F9A0A0-1EEF-4874-BAE7-CD102ABDDFEC@gmail.com> Sure. Note that I have done no real investigation of my own, though I certainly plan on it. Monit makes me a bit lazy... Here's my existing Monit rule: check process mongrel-8001 with pidfile /var/www/apps/myapp/current/ log/mongrel.8001.pid start program = "/usr/bin/ruby /usr/bin/mongrel_rails start -d - e production -p 8001 -a 127.0.0.1 -l /var/www/apps/myapp/shared/log - P log/mongrel.8001.pid -c /var/www/apps/myapp/current -B --user myuser --group mygroup" stop program = "/usr/bin/ruby /usr/bin/mongrel_rails stop -P / var/www/apps/myapp/shared/log/mongrel.8001.pid" if totalmem > 100.0 MB for 5 cycles then restart if failed port 8001 protocol http with timeout 10 seconds then restart group mongrel I'll add something like: if cpu usage > 99% for 5 cycles then restart Here's a snippit from today's monit log. Note that there was no load on the application at all at 2am or 6am. [EDT Sep 26 02:10:06] error : HTTP: error receiving data -- Resource temporarily unavailable [EDT Sep 26 02:10:06] error : 'mongrel-8002' failed protocol test [HTTP] at INET[localhost:8002] via TCP [EDT Sep 26 02:10:06] info : 'mongrel-8002' trying to restart [EDT Sep 26 02:10:06] info : 'mongrel-8002' start: /usr/bin/ruby [EDT Sep 26 02:12:10] info : 'mongrel-8002' connection passed to INET[localhost:8002] via TCP [EDT Sep 26 06:50:59] error : HTTP: error receiving data -- Resource temporarily unavailable [EDT Sep 26 06:50:59] error : 'mongrel-8001' failed protocol test [HTTP] at INET[localhost:8001] via TCP [EDT Sep 26 06:50:59] info : 'mongrel-8001' trying to restart [EDT Sep 26 06:50:59] info : 'mongrel-8001' start: /usr/bin/ruby [EDT Sep 26 06:53:03] info : 'mongrel-8001' connection passed to INET[localhost:8001] via TCP [EDT Sep 26 15:08:50] error : 'mongrel-8002' process is not running [EDT Sep 26 15:08:50] info : 'mongrel-8002' trying to restart [EDT Sep 26 15:08:50] info : 'mongrel-8002' start: /usr/bin/ruby [EDT Sep 26 15:10:58] info : 'mongrel-8002' process is running with pid 31565 I'm running RedHat EL4 (Linux eis3 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39 EST 2005 i686 i686 i386 GNU/Linux) and Mongrel 0.3.13.3 behind Apache 2.2 with mod_proxy Erik On Sep 26, 2006, at 1:35 PM, Zed A. Shaw wrote: > On Tue, 26 Sep 2006 10:32:20 -0400 > Erik Morton wrote: > >> I have a very similar stack to you and I noticed Mongrels dying once >> or twice a day. Now I'm using Monit to watch each individual Mongrel >> in the cluster and I've noticed that each Mongrel gets restarted once >> a day on average. I haven't got around to figure out the exact cause >> yet, but with Monit there is always a full cluster available. >> > > Can you turn on CPU usage monitoring with Monit and tell me if > Monit has to restart mongrel due to CPU usage? Thanks. > > -- > Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From mongrel_users at homerlex.mailshell.com Thu Sep 28 09:43:07 2006 From: mongrel_users at homerlex.mailshell.com (mongrel_users at homerlex.mailshell.com) Date: Thu, 28 Sep 2006 06:43:07 -0700 Subject: [Mongrel] Mongrel Processes Dying Message-ID: <1159450987.451bd16b7abfa@www.mailshell.com> I haven't turned on core dumps yet. Things were quite for a couple days but this morning a few processes died and I see some new Segmentation faults: /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.0/lib/action_view/base.rb:410: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i686-linux] /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.0/lib/active_record/connection_adapters/mysql_adapter.rb:148: [BUG] /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/handlers.rb:134: [BUG] /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:519: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i686-linux] /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:519: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i686-linux] -----Original Message----- From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed A. Shaw Sent: Tuesday, September 26, 2006 10:35 AM To: mongrel-users at rubyforge.org Subject: Re: [Mongrel] Mongrel Processes Dying On Tue, 26 Sep 2006 05:50:37 -0700 mongrel_users at homerlex.mailshell.com wrote: > We are seeing mongrel processes dying in our mongrel cluster. What is > the best way to troubleshoot this? > > We have ruby 1.8.4, Rails 1.1.0 (upgrading soon), MySql 4.1 running on > Red Hat Enterprise Linux ES release 4, Apache 2.2, mongrel-0.3.13.3, > mongrel_cluster-0.2.0 > > I saw the following messages in the mongrel.log but not sure if theay > are related to the processes dying. It would be nice if the log had date/time for each entry! > > /usr/local/lib/ruby/1.8/net/http.rb:562: [BUG] Segmentation fault ruby > 1.8.4 (2005-12-24) [i686-linux] These are segmentation faults inside Ruby's http code. Not sure how you're getting those but you'll need to investigate how your system is apparently totally different from everyone else's. For example, why is it in /usr/local? I'm thinking maybe you're mixing ruby installations/versions. And, it's really hard to change http.rb to produce timestamps during a segfault. Actually the fact that ruby is giving you a line number is pretty magical, so be thankful. Normally you'd have to gdb a core file for that. Which brings up another thing, turn on core dumps and that might help track it down. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu _______________________________________________________ The FREE service that prevents junk email http://www.mailshell.com From maillist at steelskies.com Thu Sep 28 13:06:19 2006 From: maillist at steelskies.com (Jonathan del Strother) Date: Thu, 28 Sep 2006 18:06:19 +0100 Subject: [Mongrel] upload_progress and DRb.start_service crashes Message-ID: Whenever I tried to start mongrel_rails with the upload progress script, it would die with the following error: /usr/local/lib/ruby/1.8/drb/drb.rb:837:in `getaddrinfo': getaddrinfo: No address associated with nodename (SocketError) from /usr/local/lib/ruby/1.8/drb/drb.rb:837:in `open_server_inaddr_any' from /usr/local/lib/ruby/1.8/drb/drb.rb:860:in `open_server' from /usr/local/lib/ruby/1.8/drb/drb.rb:756:in `open_server' from /usr/local/lib/ruby/1.8/drb/drb.rb:754:in `open_server' from /usr/local/lib/ruby/1.8/drb/drb.rb:1336:in `initialize' from /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' from /usr/local/lib/ruby/gems/1.8/gems/ mongrel_upload_progress-0.2/lib/mongrel_upload_progress/init.rb:13:in `initialize' from /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.1/lib/ gem_plugin.rb:163:in `create' ... 8 levels... from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.5/bin/ mongrel_rails:82:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.5/lib/ mongrel/command.rb:211:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.5/bin/ mongrel_rails:234 from /usr/local/bin/mongrel_rails:18 I fixed this by changing init.rb in mongrel_upload_progress - line 13 needs to supply a uri : DRb.start_service("druby://localhost:0") I suspect this is actually a bug in drb - the default uri probably shouldn't crash the process. And why isn't everyone seeing this problem? Jon -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2114 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060928/b1b7c530/attachment.bin From technoweenie at gmail.com Thu Sep 28 14:57:41 2006 From: technoweenie at gmail.com (Rick Olson) Date: Thu, 28 Sep 2006 13:57:41 -0500 Subject: [Mongrel] upload_progress and DRb.start_service crashes In-Reply-To: References: Message-ID: <48fe25b0609281157pfa0cbc0q6e0ae99abcc83a24@mail.gmail.com> On 9/28/06, Jonathan del Strother wrote: > Whenever I tried to start mongrel_rails with the upload progress > script, it would die with the following error: > > /usr/local/lib/ruby/1.8/drb/drb.rb:837:in `getaddrinfo': getaddrinfo: > No address associated with nodename (SocketError) > from /usr/local/lib/ruby/1.8/drb/drb.rb:837:in > `open_server_inaddr_any' > from /usr/local/lib/ruby/1.8/drb/drb.rb:860:in `open_server' > from /usr/local/lib/ruby/1.8/drb/drb.rb:756:in `open_server' > from /usr/local/lib/ruby/1.8/drb/drb.rb:754:in `open_server' > from /usr/local/lib/ruby/1.8/drb/drb.rb:1336:in `initialize' > from /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' > from /usr/local/lib/ruby/gems/1.8/gems/ > mongrel_upload_progress-0.2/lib/mongrel_upload_progress/init.rb:13:in > `initialize' > from /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.1/lib/ > gem_plugin.rb:163:in `create' > ... 8 levels... > from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.5/bin/ > mongrel_rails:82:in `run' > from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.5/lib/ > mongrel/command.rb:211:in `run' > from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.5/bin/ > mongrel_rails:234 > from /usr/local/bin/mongrel_rails:18 > > > I fixed this by changing init.rb in mongrel_upload_progress - line 13 > needs to supply a uri : > > DRb.start_service("druby://localhost:0") > > > I suspect this is actually a bug in drb - the default uri probably > shouldn't crash the process. And why isn't everyone seeing this > problem? > > > Jon Is that even needed? I'm not sure why that's there, since mongrel is acting as the client. The only line that should be needed is DRbObject.new(nil, options[:drb]). I'm using this right now though and haven't had issues. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com From greggpollack at gmail.com Fri Sep 29 17:44:21 2006 From: greggpollack at gmail.com (Gregg Pollack) Date: Fri, 29 Sep 2006 17:44:21 -0400 Subject: [Mongrel] Request URI Length Override In-Reply-To: <8ddc51e10609291243x1c46fcbdra3c86d920bddd084@mail.gmail.com> References: <8ddc51e10609291243x1c46fcbdra3c86d920bddd084@mail.gmail.com> Message-ID: <8ddc51e10609291444q46c7b95dl9a9991dc5edad0d1@mail.gmail.com> Please help, Does anyone know how to override the Mongrel request URI limits built in? I know it was set at a 512 byte limit, but my application will not work with this in place. Why do I need a larger limit? I've written a rails application that uses a bookmarklet to send large amounts of data from site to site. The only way to do this is (and keep it cross browser compatible) is by building and sending a large URI. Is there a way to override this? Or can someone point me in the right direction to do it myself? Thanks! -Gregg From zedshaw at zedshaw.com Fri Sep 29 19:33:57 2006 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Fri, 29 Sep 2006 16:33:57 -0700 Subject: [Mongrel] Request URI Length Override In-Reply-To: <8ddc51e10609291444q46c7b95dl9a9991dc5edad0d1@mail.gmail.com> References: <8ddc51e10609291243x1c46fcbdra3c86d920bddd084@mail.gmail.com> <8ddc51e10609291444q46c7b95dl9a9991dc5edad0d1@mail.gmail.com> Message-ID: <20060929163357.13390519.zedshaw@zedshaw.com> On Fri, 29 Sep 2006 17:44:21 -0400 "Gregg Pollack" wrote: > Please help, > > Does anyone know how to override the Mongrel request URI limits > built in? I know it was set at a 512 byte limit, but my application > will not work with this in place. > The winnar! I was wondering when this would happen. It's currently a compile time limit since nobody had ever busted through it, but it's no longer 512. It is 2k for the whole REQUEST_URI, 1024 for the REQUEST_PATH, and 10k for the QUERY_STRING. Now that I look at it that doesn't add up right (should be 11k for request_uri total). I'll update that for the next release of Mongrel and you can get it with: gem install mongrel --source=http://mongrel.rubyforge.org/releases/ > Why do I need a larger limit? I've written a rails application > that uses a bookmarklet to send large amounts of data from site to > site. The only way to do this is (and keep it cross browser > compatible) is by building and sending a large URI. How large are we talking? > Is there a way to override this? Or can someone point me in the > right direction to do it myself? > Nope, I could make it a configurable thing but it's not on the radar any time soon. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From snacktime at gmail.com Fri Sep 29 19:59:11 2006 From: snacktime at gmail.com (snacktime) Date: Fri, 29 Sep 2006 16:59:11 -0700 Subject: [Mongrel] Request URI Length Override In-Reply-To: <8ddc51e10609291444q46c7b95dl9a9991dc5edad0d1@mail.gmail.com> References: <8ddc51e10609291243x1c46fcbdra3c86d920bddd084@mail.gmail.com> <8ddc51e10609291444q46c7b95dl9a9991dc5edad0d1@mail.gmail.com> Message-ID: <1f060c4c0609291659u4b82d3f2o679e6d44a735c12f@mail.gmail.com> On 9/29/06, Gregg Pollack wrote: > Please help, > > Does anyone know how to override the Mongrel request URI limits > built in? I know it was set at a 512 byte limit, but my application > will not work with this in place. > > Why do I need a larger limit? I've written a rails application > that uses a bookmarklet to send large amounts of data from site to > site. The only way to do this is (and keep it cross browser > compatible) is by building and sending a large URI. I'm sure it's right there in the source, just search for the string 512. It's probably in mongrel.rb or defined in a file in the ext/http11 directory. But why do you think that is the only way to keep it cross browser compatible? I can't imagine that being true, as what you are doing is considered bad practice and prone to causing problems for you down the road. Chris From greggpollack at gmail.com Sat Sep 30 12:24:38 2006 From: greggpollack at gmail.com (Gregg Pollack) Date: Sat, 30 Sep 2006 12:24:38 -0400 Subject: [Mongrel] Request URI Length Override In-Reply-To: <1f060c4c0609291659u4b82d3f2o679e6d44a735c12f@mail.gmail.com> References: <8ddc51e10609291243x1c46fcbdra3c86d920bddd084@mail.gmail.com> <8ddc51e10609291444q46c7b95dl9a9991dc5edad0d1@mail.gmail.com> <1f060c4c0609291659u4b82d3f2o679e6d44a735c12f@mail.gmail.com> Message-ID: <8ddc51e10609300924t1b141793qde4801a697de4d65@mail.gmail.com> If someone can show me how to invoke a POST request using ONLY javascript, I'm all ears. You can't use any HTML (since the request is going to be coming from someone elses website), you can only use javascript to construct and send a the request, you can't include any external libraries, and the javascript is limited to around 256 characters. There's a challenge for ya ;-) -Gregg On 9/29/06, snacktime wrote: > On 9/29/06, Gregg Pollack wrote: > > Please help, > > > > Does anyone know how to override the Mongrel request URI limits > > built in? I know it was set at a 512 byte limit, but my application > > will not work with this in place. > > > > Why do I need a larger limit? I've written a rails application > > that uses a bookmarklet to send large amounts of data from site to > > site. The only way to do this is (and keep it cross browser > > compatible) is by building and sending a large URI. > > I'm sure it's right there in the source, just search for the string > 512. It's probably in mongrel.rb or defined in a file in the > ext/http11 directory. But why do you think that is the only way to > keep it cross browser compatible? I can't imagine that being true, as > what you are doing is considered bad practice and prone to causing > problems for you down the road. > > Chris > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From snacktime at gmail.com Sat Sep 30 15:07:15 2006 From: snacktime at gmail.com (snacktime) Date: Sat, 30 Sep 2006 12:07:15 -0700 Subject: [Mongrel] Request URI Length Override In-Reply-To: <8ddc51e10609300924t1b141793qde4801a697de4d65@mail.gmail.com> References: <8ddc51e10609291243x1c46fcbdra3c86d920bddd084@mail.gmail.com> <8ddc51e10609291444q46c7b95dl9a9991dc5edad0d1@mail.gmail.com> <1f060c4c0609291659u4b82d3f2o679e6d44a735c12f@mail.gmail.com> <8ddc51e10609300924t1b141793qde4801a697de4d65@mail.gmail.com> Message-ID: <1f060c4c0609301207g4d57968n4ed8696814f81b95@mail.gmail.com> On 9/30/06, Gregg Pollack wrote: > If someone can show me how to invoke a POST request using ONLY > javascript, I'm all ears. You can't use any HTML (since the request > is going to be coming from someone elses website), you can only use > javascript to construct and send a the request, you can't include any > external libraries, and the javascript is limited to around 256 > characters. > > There's a challenge for ya ;-) Your requirements don't make any sense, how are you invoking the GET without html? Since you said something about browser compatibility I'm assuming it's a link someone clicks on, and hence uses html. And what makes you assume you have to construct the request with javascript? I highly doubt that's necessary. In any case I'll bet that it's fairly simple to convert to a POST. If you need to or not is another story. IF you are submitting these large GET requests to other sites where you don't know what limits will be imposed, I would not use a GET. If it's to sites you control, or to some sort of web service/api where you know what the limits are, then it's probably not that big of a deal. IMO it's bad practice because there are too many things that can come back and bite you later on stuffing that much data into a GET request. From jan.svitok at gmail.com Sat Sep 30 15:07:29 2006 From: jan.svitok at gmail.com (Jan Svitok) Date: Sat, 30 Sep 2006 21:07:29 +0200 Subject: [Mongrel] Request URI Length Override In-Reply-To: <8ddc51e10609300924t1b141793qde4801a697de4d65@mail.gmail.com> References: <8ddc51e10609291243x1c46fcbdra3c86d920bddd084@mail.gmail.com> <8ddc51e10609291444q46c7b95dl9a9991dc5edad0d1@mail.gmail.com> <1f060c4c0609291659u4b82d3f2o679e6d44a735c12f@mail.gmail.com> <8ddc51e10609300924t1b141793qde4801a697de4d65@mail.gmail.com> Message-ID: <8d9b3d920609301207m699c490etd98a16204b922f72@mail.gmail.com> On 9/30/06, Gregg Pollack wrote: > If someone can show me how to invoke a POST request using ONLY > javascript, I'm all ears. You can't use any HTML (since the request > is going to be coming from someone elses website), you can only use > javascript to construct and send a the request, you can't include any > external libraries, and the javascript is limited to around 256 > characters. > > There's a challenge for ya ;-) I suppose XMLHttpRequest can be used for that, even though it wouldn't be easy to pack it to 256 bytes I can see another code golfing challenge ;-) (and tinyurl/rubyurl to the rescue...)