[Mongrel] [ANN] Mongrel 0.3.19 -- The Gnostic MIME Type Release
Hello All, I'm putting out a quick half-release because there's some work on the MIME types I've included that needs to be done by all of you. Read at the end to understand your role in what you started. This release features two major capitulations on Mongrel's stance of not being a full web server. The first is Mongrel now sports a YAML file with 739 MIME types in it that it will use. The second is Mongrel will now accept clients who insist on doing their requests with GET http://host:3000/index.html HTTP/1.1 even though it's not understood by a web server (that's for *proxies* people). It also features a patch to allow for multiple listeners on the request chains, so anyone running *mongrel_upload_progress* should test it heavily. Finally, we're getting close to having a clean build for win32, and my apology for holding things back on that. Install with: $ gem install fastthread --source=http://mongrel.rubyforge.org/releases $ gem install mongrel --source=http://mongrel.rubyforge.org/releases If you get an error about the missing mime_types.yml file then uninstall Mongrel completely and reinstall. THE MIME TYPES SHALL BE DECIDED BY COMBAT Now, the MIME types are not finalized because, after looking at several sources I found out everyone is completely out to lunch. I gathered together severalsources and recommended mime types, merged them all together, sorted and made them unique. I now have a wiki page entitle The Gnostic MIME Types: http://wiki.rubyonrails.org/rails/pages/TheGnosticMimeTypes And I'm going to leave it up for the next 24 hours. People can edit the list to remove what they think are invalid, correct the list, and fight over wiki wars to make the MIME type list. Whatever survives after the wars will become the official Mongrel MIME types. The ones that remain will be labeled The Gnostic MIME Types and simply documented on the Mongrel site so people know what happened. Let the battle begin! WIN32 I STILL LOVE YOU I'm still working on this last change or two and then I'm going to chain myself to win32 for the next week until that side is rock solid. Luis has been working extra hard making the sweet new service management app, so this should be a great next release for you folks. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] [ANN] Mongrel 0.3.19 -- The Gnostic MIME Type Release
I just installed this, replacing mongrel 0.3.13.4 and the single cookie issue I reported earlier is still happening. If I send multiple cookies out, only the first one is being created. The rails development log shows that all 3 cookies are being sent. START DEV LOG Cookie set: chekusername=user; domain=.website.com; path=/; expires=Fri, 15 Dec 2006 15:07:43 GMT Cookie set: chekdomain=website.com; domain=.website.com; path=/; expires=Fri, 15 Dec 2006 15:07:43 GMT Cookie set: cheksession=1234abcd1234abcd; domain=.website.com; path=/; expires=Fri, 15 Dec 2006 15:07:43 GMT Redirected to http://webmail.website.com/frame.php Completed in 0.24335 (4 reqs/sec) | DB: 0.02167 (8%) | 302 Found [http://dev.website.com/myOMC/webmail] END DEV LOG Only the chekusername cookie is set in the browser after the request is rendered. Thanks. On 12/15/06, Zed A. Shaw [EMAIL PROTECTED] wrote: Hello All, I'm putting out a quick half-release because there's some work on the MIME types I've included that needs to be done by all of you. Read at the end to understand your role in what you started. This release features two major capitulations on Mongrel's stance of not being a full web server. The first is Mongrel now sports a YAML file with 739 MIME types in it that it will use. The second is Mongrel will now accept clients who insist on doing their requests with GET http://host:3000/index.html HTTP/1.1 even though it's not understood by a web server (that's for *proxies* people). It also features a patch to allow for multiple listeners on the request chains, so anyone running *mongrel_upload_progress* should test it heavily. Finally, we're getting close to having a clean build for win32, and my apology for holding things back on that. Install with: $ gem install fastthread --source=http://mongrel.rubyforge.org/releases $ gem install mongrel --source=http://mongrel.rubyforge.org/releases If you get an error about the missing mime_types.yml file then uninstall Mongrel completely and reinstall. THE MIME TYPES SHALL BE DECIDED BY COMBAT Now, the MIME types are not finalized because, after looking at several sources I found out everyone is completely out to lunch. I gathered together severalsources and recommended mime types, merged them all together, sorted and made them unique. I now have a wiki page entitle The Gnostic MIME Types: http://wiki.rubyonrails.org/rails/pages/TheGnosticMimeTypes And I'm going to leave it up for the next 24 hours. People can edit the list to remove what they think are invalid, correct the list, and fight over wiki wars to make the MIME type list. Whatever survives after the wars will become the official Mongrel MIME types. The ones that remain will be labeled The Gnostic MIME Types and simply documented on the Mongrel site so people know what happened. Let the battle begin! WIN32 I STILL LOVE YOU I'm still working on this last change or two and then I'm going to chain myself to win32 for the next week until that side is rock solid. Luis has been working extra hard making the sweet new service management app, so this should be a great next release for you folks. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] Early morning strange error saying: Status: 500 Internal Server Error
Have you ruled out the MySQL connection timeout issue? Erik On Dec 15, 2006, at 10:01 AM, Matthew Whittaker wrote: So I have updated to the latest mongrel and fastthread and my environment is as follows: Debian 3.1 Rails 1.1.6 Ruby 1.8.5 Mongrel 0.3.18 Fastthread 0.4 Mongrel Cluster 0.2.1 Apache 2.2.3 I again woke up this morning to my disappointment of seeing the strange Status: 500 Internal Server error. It happens the same every morning, I have three mongrels running, two give the error, one processes the request successfully. This error is not being reported in ANY logs. Apache, Mongrel debug, rails, nothing. The only thing I notice while tailing the logs is that the request reaches mongrel and is reported in both rails.log and threads.log, however the request is NOT being reported in ruby / rails production.log. This appears to be craping out in mongrel. Again this only happens overnight when there is no activity with the site. PLEASE HELP. Is there any way to take a core dump of mongrel? How can I get more logs to see what is happening. Regards, Matt Whittaker ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] Early morning strange error saying: Status: 500 Internal Server Error
I second this. These symptoms are very similar to something that I experienced and the culprit ended up being the MySql timeout issue. I talk more about my solution here: http://rubyforge.org/pipermail/mongrel-users/2006-November/002178.html Cheers, Steven Erik Morton wrote: Have you ruled out the MySQL connection timeout issue? Erik On Dec 15, 2006, at 10:01 AM, Matthew Whittaker wrote: So I have updated to the latest mongrel and fastthread and my environment is as follows: Debian 3.1 Rails 1.1.6 Ruby 1.8.5 Mongrel 0.3.18 Fastthread 0.4 Mongrel Cluster 0.2.1 Apache 2.2.3 I again woke up this morning to my disappointment of seeing the strange Status: 500 Internal Server error. It happens the same every morning, I have three mongrels running, two give the error, one processes the request successfully. This error is not being reported in ANY logs. Apache, Mongrel debug, rails, nothing. The only thing I notice while tailing the logs is that the request reaches mongrel and is reported in both rails.log and threads.log, however the request is NOT being reported in ruby / rails production.log. This appears to be craping out in mongrel. Again this only happens overnight when there is no activity with the site. PLEASE HELP. Is there any way to take a core dump of mongrel? How can I get more logs to see what is happening. Regards, Matt Whittaker ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] Early morning strange error saying: Status: 500 Internal Server Error
Thanks, I will look into it. Cheers, Matt On Dec 15, 2006, at 10:36 AM, Steven Hansen wrote: I second this. These symptoms are very similar to something that I experienced and the culprit ended up being the MySql timeout issue. I talk more about my solution here: http://rubyforge.org/pipermail/mongrel-users/2006-November/002178.html Cheers, Steven Erik Morton wrote: Have you ruled out the MySQL connection timeout issue? Erik On Dec 15, 2006, at 10:01 AM, Matthew Whittaker wrote: So I have updated to the latest mongrel and fastthread and my environment is as follows: Debian 3.1 Rails 1.1.6 Ruby 1.8.5 Mongrel 0.3.18 Fastthread 0.4 Mongrel Cluster 0.2.1 Apache 2.2.3 I again woke up this morning to my disappointment of seeing the strange Status: 500 Internal Server error. It happens the same every morning, I have three mongrels running, two give the error, one processes the request successfully. This error is not being reported in ANY logs. Apache, Mongrel debug, rails, nothing. The only thing I notice while tailing the logs is that the request reaches mongrel and is reported in both rails.log and threads.log, however the request is NOT being reported in ruby / rails production.log. This appears to be craping out in mongrel. Again this only happens overnight when there is no activity with the site. PLEASE HELP. Is there any way to take a core dump of mongrel? How can I get more logs to see what is happening. Regards, Matt Whittaker ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
[Mongrel] running mongrel in production on win32
Hey guys, I'm running the mongrel server that comes with rails-1.2rc1 for development on a winxp box, anticipating taking it into production on a win2k3 box in the next few weeks. I've had a couple of crashes occur during development that give me pause, however. I made a ticket for the last one here: http://dev.rubyonrails.org/ticket/6841 I know, or at least believe, that mongrel isn't responsible for these, but I'm curious if or how folks maintain stable production services relying on mongrel on win32. If installed as a service, does the service restart cleanly if the mongrel instance crashes? (I've seen reports to indicate this is not the case.) Am I just asking for trouble pursuing this as a production environment? Is the mongrel_cluster code ready for primetime on win32 yet? Thanks for any tips. Cheers. - donald ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] running mongrel in production on win32
On 12/15/06, Ball, Donald A Jr (Library) [EMAIL PROTECTED] wrote: Hey guys, I'm running the mongrel server that comes with rails-1.2rc1 for development on a winxp box, anticipating taking it into production on a win2k3 box in the next few weeks. Ok, which version of mongrel is bundled with rails-1.2? Please list the gems you have installed, because, AFAIK, script\server will only load mongrel if the gem is found. You are starting it using mongrel_rails or script/server? I've had a couple of crashes occur during development that give me pause, however. I made a ticket for the last one here: http://dev.rubyonrails.org/ticket/6841 That bug seems weird, also unrelated to rails but Ruby itself. I know, or at least believe, that mongrel isn't responsible for these, but I'm curious if or how folks maintain stable production services relying on mongrel on win32. If installed as a service, does the service restart cleanly if the mongrel instance crashes? (I've seen reports to indicate this is not the case.) Am I just asking for trouble pursuing this as a production environment? Is the mongrel_cluster code ready for primetime on win32 yet? Lastest mongrel_service gem provide what you need, if somehow the ruby process die (due a unhandled exception) the service will automatically spawn a new one. There is no way (yet, still need to test some things) to monitor deeply if the ruyb process hang and not die. The mongrel_cluster base his magic on daemonize, which requires fork() and isn't compatible with win32. Its planned for mongrel_service to provide this functionality, maybe during january. Thanks for any tips. Cheers. - donald Will be very helpful if you provide more information about your database (and version), mongrel, rails, ruby and windows version to we could get a better picture of your situation. Regards and good weekend, -- 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@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] Early morning strange error saying: Status: 500 Internal Server Error
I, too had a similar problem - which persisted even after I inserted this: ActiveRecord::Base.verification_timeout = 14400 Into my config/production.rb On close inspection of my apache logs I discovered that a robot was hitting my application with a (near) simultaneous pair of get requests with identical session_id's. The session_id was new - and so both rails processes attempted to insert a new record into the session table, causing the database to report a duplicate key violation on the second insert. Apparently the second rails process determined that the session_id was new before the first rails process had finished its insert. Hope this is helpful. Robert ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
[Mongrel] RMagick=bad, ???=good
I know that Zed has made mention of the fact that using RMagick with mongrel and rails is a bad thing. I'm currently using FlexImage (which in turn uses RMagick) on my application and really haven't had too many problems. We get a restart for memory usage every 8-10 hours on one mongrel of twelve running, but I'm not sure if that's an RMagick issue. Either way, I'd like to make my system better if I can. Right now I've got controllers that are using both send_data (sending image stored in the db, using RMagick to crop/resize before sending) and send_file (sending a static image on the site that needs to be sent inline). Image upload is being handled by FlexImage, which will save the image to the DB, resizing it to 640x480 before saving if it's too big. My question is, what then is the preferred method of doing image manipulation while running mongrel? Convert FlexImage to use mini-magick? Create a custom system to offload the image processing to another process? If someone can provide some insight or examples, it would be appreciated. ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] Debugging high CPU with Mongrel
Alright so I got fastthread installed yesterday. Unfortunately the massive load spike happened again (until rails cache was deleted of course). I'm just wondering if I'm using killall -USR1 mongrel_rails the proper way. What sort of messages should I be looking for? They are suppose to be in mongrel.log right? Other than turning the toggling debugging mode to true I don't seem to be getting any extra info in that mongrel.log or production.log. Is there some lower level thing I can try? If it really is a cache thing and there is a way for me to see it stuck in some process loading or building a fragment or something... Are the 0.3.19pr items pretty much centered around the MIME type stuff or should I try upgrading to that from .18pr? Thanks Again, Dallas On 12/14/06, Dallas DeVries [EMAIL PROTECTED] wrote: Thanks I will give it a whirl. I assume I just need to do this with the mongrel 0.3.18pr I have gem install fastthread --source= http://mongrel.rubyforge.org/releases/ Thanks! Dallas On 12/14/06, Jacob Atzen [EMAIL PROTECTED] wrote: On Wed, Dec 13, 2006 at 09:41:27PM -0500, Dallas DeVries wrote: Alright, so I started clean on a different machine (3Ghz, 2 Gigs RAM) -pen/mongrel (tried prerelease and stable - 7 instances) - apache/mongrel_cluster/mongrel prerelease (9 instances) -debian sarge - ubuntu stable Unfortunately I'm still getting hangs. Things run fine for hours at a time and tens of thousands of page hits. Are you using mentalguy's fastthread? If not, try it out and see if it helps. -- Cheers, - Jacob Atzen ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] RMagick=bad, ???=good
On Fri, 15 Dec 2006 11:14:20 -0600 Joey Geiger [EMAIL PROTECTED] wrote: I know that Zed has made mention of the fact that using RMagick with mongrel and rails is a bad thing. I'm currently using FlexImage (which in turn uses RMagick) on my application and really haven't had too many problems. We get a restart for memory usage every 8-10 hours on one mongrel of twelve running, but I'm not sure if that's an RMagick issue. Either way, I'd like to make my system better if I can. Right now I've got controllers that are using both send_data (sending image stored in the db, using RMagick to crop/resize before sending) and send_file (sending a static image on the site that needs to be sent inline). Image upload is being handled by FlexImage, which will save the image to the DB, resizing it to 640x480 before saving if it's too big. My question is, what then is the preferred method of doing image manipulation while running mongrel? Convert FlexImage to use mini-magick? Create a custom system to offload the image processing to another process? If someone can provide some insight or examples, it would be I work on a shall not be named here large Web site devoted to handling large numbers of photographic imagery. Although our site is not running in Ruby, yet, we have worked through a number of approaches to handling this, but only one has the desired properties we need, which is automatic recovery and minimal impact to running code on failure: exec out another process to do image manipulation. If you're doing something small, feel free to use RMagick+death+recovery if you want, but exec-ing out really is the way to go. Jim signature.asc Description: PGP signature ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] RMagick=bad, ???=good
Just to chime in - we are using RMagick with Gruff on mongrel/apache combo without any memory leaks or restart problems. Our cluster happily runs for weeks at a time, before we restart it (usual because of new code released). I am also curious to know what specific problems are reported related to RMagick. Thanks Konstantin On Dec 15, 2006, at 9:14 AM, Joey Geiger wrote: I know that Zed has made mention of the fact that using RMagick with mongrel and rails is a bad thing. I'm currently using FlexImage (which in turn uses RMagick) on my application and really haven't had too many problems. We get a restart for memory usage every 8-10 hours on one mongrel of twelve running, but I'm not sure if that's an RMagick issue. Either way, I'd like to make my system better if I can. Right now I've got controllers that are using both send_data (sending image stored in the db, using RMagick to crop/resize before sending) and send_file (sending a static image on the site that needs to be sent inline). Image upload is being handled by FlexImage, which will save the image to the DB, resizing it to 640x480 before saving if it's too big. My question is, what then is the preferred method of doing image manipulation while running mongrel? Convert FlexImage to use mini-magick? Create a custom system to offload the image processing to another process? If someone can provide some insight or examples, it would be appreciated. ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] RMagick=bad, ???=good
Although our site is
not running in Ruby, yet, we have worked through a number of
approaches
to handling this, but only one has the desired properties we need,
which is automatic recovery and minimal impact to running code on
failure: exec out another process to do image manipulation.
I must admit that we do the same thing at 37signals. But actually not
because of memory leaks, but because we found it easier to do:
def thumbnail(temp, target)
system convert #{escape(temp)} -resize 48x48! #{escape(target)}
end
Rather than to get the full RMagick machinery cooking.
--
David Heinemeier Hansson
http://www.37signals.com-- Basecamp, Campfire, Backpack, Getting
Real
http://www.rubyonrails.com -- Web-application framework
http://www.loudthinking.com -- Broadcasting Brain
smime.p7s
Description: S/MIME cryptographic signature
___
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users
[Mongrel] Help w/ Apache Proxying Mongrel
I'm running Apache 2.0 as a proxy to several Mongrel/Rails apps, so that all of my Mongrel apps can be routed through the single Apache IP address. Apache 2.0 is already in use on the system, which is why I haven't decided to use Apache 2.2. The problem I'm having is that this setup only works for Rails apps that do not use the public/index.html file as the main page. For any apps that do use public/index.html as the main page, none of the links off of index.html work. So no stylesheet info, no images, and no links to other parts of the application. Even though I've installed the reverse_proxy_fix plugin. The tutorial from here (http://www.napcsweb.com/howto/rails/deployment/RailsWithApacheAndMong... http://www.napcsweb.com/howto/rails/deployment/RailsWithApacheAndMongrel.pd f ) didn't cover this type of error, and I've been stuck fiddling with it for a while. Has anyone else had this problem and resolved it? Any help is much appreciated. My httpd-proxy.conf file is included below: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so ProxyRequests Off Proxy * Order deny,allow Allow from all /Proxy #Proxy information for project application Alias /project e:/rails_apps/project/public Directory e:/rails_apps/project/public Options Indexes FollowSymLinks AllowOverride none Order allow,deny Allow from all /Directory ProxyPass /project/images ! ProxyPass /project/stylesheets ! ProxyPass /project/javascripts ! ProxyPass /project/ http://127.0.0.1:4000/ ProxyPass /project http://127.0.0.1:4000/ ProxyPassReverse /project/ http://127.0.0.1:4000/ #Proxy information for research guides application #this is the application not working properly Alias /research e:/rails_apps/research/public Directory e:/rails_apps/research/public Options Indexes FollowSymLinks AllowOverride none Order allow,deny Allow from all /Directory ProxyPass /research/images ! ProxyPass /research/stylesheets ! ProxyPass /research/javascripts ! ProxyPass /research/ http://127.0.0.1:4002/ ProxyPass /research http://127.0.0.1:4002/ ProxyPassReverse /research/ http://127.0.0.1:4002/ Thanks! -- Nathan Mealey Systems Librarian Simmons College 617.521.2755 [EMAIL PROTECTED] ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] running mongrel in production on win32
On 12/15/06, Ball, Donald A Jr (Library) [EMAIL PROTECTED] wrote: Hey guys, I'm running the mongrel server that comes with rails-1.2rc1 for development on a winxp box, anticipating taking it into production on a win2k3 box in the next few weeks. Ok, which version of mongrel is bundled with rails-1.2? Please list the gems you have installed, because, AFAIK, script\server will only load mongrel if the gem is found. I'm using mongrel-0.3.13.3-mswin32, the latest publicly available mswin32 gem, along with mongrel_service-0.2, though I'm not using the service in development. I tried to install 0.3.19 but got odd compilation warnings when I did so and the server failed to start. You are starting it using mongrel_rails or script/server? script/server I've had a couple of crashes occur during development that give me pause, however. I made a ticket for the last one here: http://dev.rubyonrails.org/ticket/6841 That bug seems weird, also unrelated to rails but Ruby itself. So you believe I've run into a bug in ruby-1.8.4-mswin32? Looked to me more like an unhandled exception in activesupport, but the rails folks seemed to think that was not the case. Lastest mongrel_service gem provide what you need, if somehow the ruby process die (due a unhandled exception) the service will automatically spawn a new one. I'll give that a whirl, thanks! Would the log files indicate when/if this occurs? There is no way (yet, still need to test some things) to monitor deeply if the ruyb process hang and not die. The mongrel_cluster base his magic on daemonize, which requires fork() and isn't compatible with win32. Its planned for mongrel_service to provide this functionality, maybe during january. If I can help in this endeavor in any way, please let me know. I'm a beginning ruby developer, but I've been doing web development for time out of mind and I have a copy of visual studio 2003 if needed for compilation. Will be very helpful if you provide more information about your database (and version), mongrel, rails, ruby and windows version to we could get a better picture of your situation. Sure thing. I'm using mssql2k with the ADO driver, mongrel-0.3.13.3, rails-1.2rc1, ruby-1.8.4, winxpsp2 (but will be deploying to win2k3). I am using RMagick with file_column, though the crashes have not (yet) occurred while testing that portion of the application. Regards and good weekend, Thanks for your help and for your work in providing rails folks with a potentially workable solution for win32 deployment! It would not be my choice for a production environment, but it's out of my hands. - donald ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] RMagick=bad, ???=good
On 12/15/06, David Heinemeier Hansson [EMAIL PROTECTED] wrote:
Although our site is
not running in Ruby, yet, we have worked through a number of
approaches
to handling this, but only one has the desired properties we need,
which is automatic recovery and minimal impact to running code on
failure: exec out another process to do image manipulation.
I must admit that we do the same thing at 37signals. But actually not
because of memory leaks, but because we found it easier to do:
def thumbnail(temp, target)
system convert #{escape(temp)} -resize 48x48! #{escape(target)}
end
Rather than to get the full RMagick machinery cooking.
There's also minimagick, which is a shell around imagemagick commands.
Probably easier if you want to do more complex operations on your
images.
Oh, and ImageScience, which uses FreeImage and a light inline ruby
wrapper. http://seattlerb.rubyforge.org/ImageScience.html
--
Rick Olson
http://weblog.techno-weenie.net
http://mephistoblog.com
___
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] RMagick=bad, ???=good
I know that Zed has made mention of the fact that using RMagick with mongrel and rails is a bad thing. I'm currently using FlexImage (which in turn uses RMagick) on my application and really haven't had too many problems. We get a restart for memory usage every 8-10 hours on one mongrel of twelve running, but I'm not sure if that's an RMagick issue. Either way, I'd like to make my system better if I can. Right now I've got controllers that are using both send_data (sending image stored in the db, using RMagick to crop/resize before sending) and send_file (sending a static image on the site that needs to be sent inline). Image upload is being handled by FlexImage, which will save the image to the DB, resizing it to 640x480 before saving if it's too big. My question is, what then is the preferred method of doing image manipulation while running mongrel? Convert FlexImage to use mini-magick? Create a custom system to offload the image processing to another process? If someone can provide some insight or examples, it would be appreciated. Just to add to what others have said there is also the GD2 library and if you're willing to shell out, netpbm. Although I would imagine GD2 has the same potential for memory leaks as ImageMagick if I understand the issue correctly (that is ruby not knowing about memory allocated by the extension). We use rmagick now, but don't upload that many images (admin interface only). My last job (not Rails, but that doesn't matter) we shelled out to netpbm for a couple of reasons -- we were dealing with a lot of arcane formats (PCX with specific header formats) and because I'd run some tests converting/scaling images using GD, ImageMagick, and netpbm and netpbm seemed to do the best job and delivery the smallest file. Now... that was about six years ago so things may certainly have changed. -philip ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] [ANN] Mongrel 0.3.19 -- The Gnostic MIME Type Release
On Fri, 15 Dec 2006 08:42:15 -0600 Joey Geiger [EMAIL PROTECTED] wrote: I just installed this, replacing mongrel 0.3.13.4 and the single cookie issue I reported earlier is still happening. If I send multiple cookies out, only the first one is being created. The rails development log shows that all 3 cookies are being sent. Yeah, I remembered that I missed this last night. Next release it'll have a whitelist for the cookies that should be allowed to duplicate (and you can modify it if you need to). Thanks for catching this. I'll be doing another release tonight so try it then. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Re: [Mongrel] Debugging high CPU with Mongrel
On Fri, 15 Dec 2006 12:36:47 -0500 Dallas DeVries [EMAIL PROTECTED] wrote: Alright so I got fastthread installed yesterday. Unfortunately the massive load spike happened again (until rails cache was deleted of course). I'm just wondering if I'm using killall -USR1 mongrel_rails the proper way. What sort of messages should I be looking for? They are suppose to be in mongrel.log right? Other than turning the toggling debugging mode to true I don't seem to be getting any extra info in that mongrel.log or production.log. Is there some lower level thing I can try? If it really is a cache thing and there is a way for me to see it stuck in some process loading or building a fragment or something... If you turn on USR1 and don't see any log messages than most likely it's a problem that isn't triggering one of the exceptions. You're turning it on right, and you should see a little log message saying it's on. If you've got a process that's stuck for some reason, try strace -p PID. Using strace you can see what system calls the process is calling and then see if it's in some loop or something. Another option--which is more advanced--is to attach to the process with gdb and then interrupt it and step through. I haven't used this yet, but check out Jamis Buck's blog and a few others for handy macros that can dump the Ruby callstack. Are the 0.3.19pr items pretty much centered around the MIME type stuff or should I try upgrading to that from .18pr? Yeah, it's MIME that was put into the 0.3.19 and just a few fastthread changes. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
[Mongrel] [ANN] Mongrel 0.3.20 -- 5 Hours Deadline
Another fancy release with just a few little changes from yesterday: * Set-Cookie, Set-Cookie2, Warning, and WWW-Authenticate are allowed as duplicate headers. * mongrel_rails stop now has a --wait option to go with --force. It will wait for either the given timeout in SECONDS or the PID file to go away. If the PID file goes away it just exits. If the timeout happens then it does a kill -9 on the mongrel process. * The MIME types as of 22:00 PDT are included in this release. Five more hours to make changes and complain if you don't like them. Edit the wiki: to make a difference. * Default MIME type is application/octet-stream (it was with 0.3.19, but now you all know). Install with: $ gem install fastthread --source=http://mongrel.rubyforge.org/releases $ gem install mongrel --source=http://mongrel.rubyforge.org/releases This release will be what goes in the 1.0 RC1 with the exception of any changes we have to make for win32 and the final version of the MIME types. 5 HOURS LEFT Make sure you edit the MIME types wiki: http://wiki.rubyonrails.org/rails/pages/TheGnosticMimeTypes It looks like lots of types have mapping from one extension to two types. In the case of a tie like this I'll have a program randomly pick. :-) USING THE FORCE Mongrel is *very* conservative when it shuts down. It will wait up to 60 seconds for threads to exit before it finally exits gracefully. Most people don't understand this so they think Mongrel is stuck, when actually it's doing what everyone also wants which is not lose a single connection. The hypocrisy is that people want Mongrel's shutdown to be robust but mean two things. Robust when you've gotta have Mongrel down NOW to avoid the digg to your fancy social network mashup with potato porn means down now! now! NOW! don't wait! NOW! Robust when you're rolling out the latest version of your crafted ultimate killer online PIM software your company has banked its reputation on means very carefully, we don't want to lose a single byte in any request ever. Don't ask me why these people are using HTTP but oh well. Mongrel is robust in the second form. To make Mongrel robust in the first form, you use the force: $ mongrel_rails stop --force This sends mongrel a kill -9 and then *you* must delete the .pid file. If you don't mongrel now does this when you try to start: $ mongrel_rails start -e production -d ** !!! PID file log/mongrel.pid already exists. Mongrel could be running already. Check your log/mongrel.log for errors. ** !!! Exiting with error. You must stop mongrel and clear the .pid before I'll attempt a start. So, if you had to force it down, you've gotta do the clean-up. Now, let's say you do want to give most requests a chance to get out, but maybe not the usual time, you can now use --wait with force: $ mongrel_rails stop --force --wait 15 The --wait parameter only makes sense with --force. When you do this, Mongrel will watch the mongrel.pid file for 15 seconds. If the PID file goes away on its own (meaning the process exited anyway) then the stop command is ignored and mongrel_rails exits. If 15 seconds pass by and the PID file is still there *then* mongrel sends kill -9 to ruin your customer's day. But don't worry, you've probably planned your outages and have scheduled this with your customers and have come back later pages right? -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. ___ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
