From garry at ascii-turf.net  Tue Jul  3 12:50:56 2007
From: garry at ascii-turf.net (Garry Hill)
Date: Tue, 3 Jul 2007 17:50:56 +0100
Subject: [Swiftiply-users] swiftiply, mongrel and upload_progress
Message-ID: <247EC1A9-0E92-43F7-8B33-4C2EE157744F@ascii-turf.net>



Hi there,

Does anyone know why swiftiply breaks zed's upload_progress mongrel  
plugin?

I'm very interested in using swiftiply with mongrel (i like the idea  
of increased stability above all else) but the main reason i'm using  
mongrel is the availability of the upload_progress handler  
(documented here: <http://mongrel.rubyforge.org/docs/ 
upload_progress.html>).

With the upload_progress debugging turned on it seems that an  
'evented' mongrel isn't passing on the 'request_begins' or  
'request_progress' messages that the handler uses, but it is getting  
the final 'process' call.

Would it be possible to get these swiftiply and upload_progress to  
play together, or is there something about the way that swiftiply  
works that makes these two incompatible?

Best,

Garry


From wyhaines at gmail.com  Tue Jul  3 13:05:07 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 3 Jul 2007 10:05:07 -0700
Subject: [Swiftiply-users] swiftiply, mongrel and upload_progress
In-Reply-To: <247EC1A9-0E92-43F7-8B33-4C2EE157744F@ascii-turf.net>
References: <247EC1A9-0E92-43F7-8B33-4C2EE157744F@ascii-turf.net>
Message-ID: <f4cd26df0707031005m25447b55r78b950bc212a49bd@mail.gmail.com>

On 7/3/07, Garry Hill <garry at ascii-turf.net> wrote:

> Does anyone know why swiftiply breaks zed's upload_progress mongrel
> plugin?
>
> I'm very interested in using swiftiply with mongrel (i like the idea
> of increased stability above all else) but the main reason i'm using
> mongrel is the availability of the upload_progress handler
> (documented here: <http://mongrel.rubyforge.org/docs/
> upload_progress.html>).

That's the first that this has been reported to me, so I will look into it.

A couple questions:

1) Are you using evented_mongrel, or Swiftiply with swiftiplied_mongrel?

2) Would it be possible for you to give to me a simple test case that
works under threaded mongrel but breaks under evented/swiftiplied
mongrel?


Thanks,

Kirk Haines

From garry at ascii-turf.net  Tue Jul  3 13:48:37 2007
From: garry at ascii-turf.net (Garry Hill)
Date: Tue, 3 Jul 2007 18:48:37 +0100
Subject: [Swiftiply-users] swiftiply, mongrel and upload_progress
In-Reply-To: <f4cd26df0707031005m25447b55r78b950bc212a49bd@mail.gmail.com>
References: <247EC1A9-0E92-43F7-8B33-4C2EE157744F@ascii-turf.net>
	<f4cd26df0707031005m25447b55r78b950bc212a49bd@mail.gmail.com>
Message-ID: <2ACD0274-EB4A-47DA-A18D-C94D9B81FA78@ascii-turf.net>


Hi,

> That's the first that this has been reported to me, so I will look  
> into it.

Ok, great.

> 1) Are you using evented_mongrel, or Swiftiply with  
> swiftiplied_mongrel?

I'm using a single evented_mongrel instance. mongrel 1.0.1, ruby  
1.8.6, OS X 10.4.

> 2) Would it be possible for you to give to me a simple test case that
> works under threaded mongrel but breaks under evented/swiftiplied
> mongrel?

Here's a very basic rails app stubbed out from the upload_progress  
instructions on the mongrel site:

<http://fairynuff.net/upload_progress.tgz>

tar xzvf upload_progress.tgz
cd eventified_upload_progress
mongrel_rails start -p 3000 -S config/mongrel_upload_progress.conf

The upload form is here:

http://localhost:3000/files/create

You might want to use some kind of throttling proxy (I'm using  
'charles') otherwise you'll have to upload huge files to see any kind  
of progress indication at all. You do see debug messages from  
upload_progress even if the upload is too fast to register in the js  
progress bar though, e.g. "1183484688: Added" which is one you won't  
see if it's not working.

Running the app as above gives you progress feedback. You can see in  
the development.log messages like "Upload status  
{:received=>46378, :size=>177450}" which means it's running fine.

However with an evented mongrel

$ EVENT=1 mongrel_rails start -p 3000 -S config/ 
mongrel_upload_progress.conf

Those log messages become "Upload status nil" because the handler  
hasn't registered the upload.

Note: I've never figured out how to turn on debugging in the  
upload_handler through config options, in theory you add in a :debug  
=> 1 to the conf, but that's never worked. To force upload_progress'  
debugging output change line 18 of its init.rb script to

Mongrel::Uploads.debug = true # if options[:debug]

Is that enough for you to work with?

Best,

Garry




From wyhaines at gmail.com  Tue Jul  3 14:54:44 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 3 Jul 2007 11:54:44 -0700
Subject: [Swiftiply-users] swiftiply, mongrel and upload_progress
In-Reply-To: <2ACD0274-EB4A-47DA-A18D-C94D9B81FA78@ascii-turf.net>
References: <247EC1A9-0E92-43F7-8B33-4C2EE157744F@ascii-turf.net>
	<f4cd26df0707031005m25447b55r78b950bc212a49bd@mail.gmail.com>
	<2ACD0274-EB4A-47DA-A18D-C94D9B81FA78@ascii-turf.net>
Message-ID: <f4cd26df0707031154j3d4c6763k9cf2b83116a74a6a@mail.gmail.com>

On 7/3/07, Garry Hill <garry at ascii-turf.net> wrote:
> Is that enough for you to work with?

Perfect.  Thanks.


Kirk Haines

From doug.wright at quest.com  Tue Jul 10 11:39:02 2007
From: doug.wright at quest.com (Doug Wright)
Date: Tue, 10 Jul 2007 08:39:02 -0700
Subject: [Swiftiply-users] simulataneous requests don't respond
Message-ID: <EDDA3468236C4D4886EFE3E69B4A704C026CD56D@ALVMBXW05.prod.quest.corp>

Hi.  First of all, thank you for making such a cool project available!
I am attempting to use swiftiply to create an elasticly scaling app
using amazon ec2.  The first step for me is to successfully run an app
proxied by swiftiply and profile it using jmeter to prove that adding
more backend servers improves response times under heavy load.  My
backend app intentionally sleeps for 5 seconds before responding so that
I can simulate a time-intensive request.  Unfortunately, I'm having
problems here. 

 

I'm able to service a single request fine as well as single-threaded
repeated requests using jmeter or my browser.  However, if I make
requests in multiple threads simultaneously (or just click on my request
link in my browser a second time before the first request comes back),
the second request just hangs.  It doesn't appear to ever time out.
This causes jmeter to lock up after the second thread launches and it
makes it impossible for me to load test swiftiply in my situation.

 

Is there anything I might be doing wrong that would cause these results?
Might this be a bug?  I appreciate any help or advice you can give me.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/swiftiply-users/attachments/20070710/c74448e6/attachment-0001.html 

From doug.wright at quest.com  Tue Jul 10 12:40:08 2007
From: doug.wright at quest.com (Doug Wright)
Date: Tue, 10 Jul 2007 09:40:08 -0700
Subject: [Swiftiply-users] simulataneous requests don't respond
Message-ID: <EDDA3468236C4D4886EFE3E69B4A704C026CD59E@ALVMBXW05.prod.quest.corp>

Hi.  First of all, thank you for making such a cool project available!
I am attempting to use swiftiply to create an elasticly scaling app
using amazon ec2.  The first step for me is to successfully run an app
proxied by swiftiply and profile it using jmeter to prove that adding
more backend servers improves response times under heavy load.  My
backend app intentionally sleeps for 5 seconds before responding so that
I can simulate a time-intensive request.  Unfortunately, I'm having
problems here. 

 

I'm able to service a single request fine as well as single-threaded
repeated requests using jmeter or my browser.  However, if I make
requests in multiple threads simultaneously (or just click on my request
link in my browser a second time before the first request comes back),
the second request just hangs.  It doesn't appear to ever time out.
This causes jmeter to lock up after the second thread launches and it
makes it impossible for me to load test swiftiply in my situation.

 

Is there anything I might be doing wrong that would cause these results?
Might this be a bug?  I appreciate any help or advice you can give me.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/swiftiply-users/attachments/20070710/0c8f1aac/attachment.html 

From jed.hurt at gmail.com  Fri Jul 27 19:20:00 2007
From: jed.hurt at gmail.com (Jed Hurt)
Date: Fri, 27 Jul 2007 17:20:00 -0600
Subject: [Swiftiply-users] Varnish -> Swiftiply -> Mongrel
Message-ID: <dbc32d450707271620m7eea7afdl87e92d356f25166f@mail.gmail.com>

I heard about a new HTTP Accelerator called Varnish (
http://varnish.projects.linpro.no/ ) on Joyeur (Joyent's blog). Since
Swiftiply is slated to receive static file and SSL support soon, I'm
wondering, "What would be the feasability of dropping the web server
altogether and just use Varnish and Swiftiply?"

Myself, I'm really just a Rails developer. Not a sysadmin. Would this
setup even be conceptually possible?

From wyhaines at gmail.com  Fri Jul 27 19:30:30 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Fri, 27 Jul 2007 16:30:30 -0700
Subject: [Swiftiply-users] Varnish -> Swiftiply -> Mongrel
In-Reply-To: <dbc32d450707271620m7eea7afdl87e92d356f25166f@mail.gmail.com>
References: <dbc32d450707271620m7eea7afdl87e92d356f25166f@mail.gmail.com>
Message-ID: <f4cd26df0707271630i767087eu2abc6561db31d67c@mail.gmail.com>

On 7/27/07, Jed Hurt <jed.hurt at gmail.com> wrote:
> I heard about a new HTTP Accelerator called Varnish (
> http://varnish.projects.linpro.no/ ) on Joyeur (Joyent's blog). Since
> Swiftiply is slated to receive static file and SSL support soon, I'm
> wondering, "What would be the feasability of dropping the web server
> altogether and just use Varnish and Swiftiply?"
>
> Myself, I'm really just a Rails developer. Not a sysadmin. Would this
> setup even be conceptually possible?

Abso-freakin'-lutely!

I'm not using Varnish, but am running the pre-0.6.0 Swiftiply this way
now, and I have been for a while.

The static file support still has some naiveties (it isn't yet
supporting etag/if-modifed/if-modified-since headers), but it's quite
fast.  I'll probably release the etag/etc. support as 0.6.1 or 0.6.2
as I work towards the 0.7.0 release.

There is a new EM slated to be released this weekend.  As soon as I
see it hit the shelves, I'll release Swiftiply 0.6.0.


Kirk Haines

From ni-di at web.de  Tue Jul 31 08:49:04 2007
From: ni-di at web.de (Niko Dittmann)
Date: Tue, 31 Jul 2007 14:49:04 +0200
Subject: [Swiftiply-users] 'start_tcp_server': no acceptor error
Message-ID: <3DAFD60B-7630-45DB-874E-15876D25C1A0@web.de>

Hi everybody,


I just started playing around with swiftiply and I get the following  
error when starting mongrel:

# env SWIFT=1 mongrel_rails start -p 4000
Using Evented Mongrel
** Ruby version is not up-to-date; loading cgi_multipart_eof_fix
** Starting Mongrel listening at 0.0.0.0:4000
** Starting Rails with development environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no  
restart).
** Rails signals registered.  HUP => reload (without restart).  It  
might not work well.
** Mongrel available at 0.0.0.0:4000
** Use CTRL-C to stop.
/usr/lib/ruby/gems/1.8/gems/eventmachine-0.8.1/lib/eventmachine.rb: 
476:in `start_tcp_server': no acceptor (RuntimeError)
from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ 
configurator.rb:293:in `join'
...

I'm using ruby 1.8.5 (2006-08-25) [i486-linux], swiftiply-0.5.1 and  
my configuration looks like this:

{"cluster_address"=>"www.my-domain.com",
"timeout"=>3,
"map"=>
   [{"default"=>true,
     "outgoing"=>["localhost:4000"],
     "keepalive"=>true,
     "incoming"=>["www.my-domain.com"]}],
"cluster_port"=>8000,
"daemonize"=>false}

I've set up this high cluster port to be shure to avoid any low port  
problems.

I've set the env-variable: export SWIFT=1

I'm starting swiftiply (atm as root) first and it's running quietly  
(I wish there was a verbose mode).  Then I start one mongrel (atm as  
root) by running

env SWIFT=1 mongrel_rails start -p 4000     # OR
swiftiply_mongrel_rails

and either result is the above error message (with the only  
difference being that when using swiftiply_mongrel_rails the "Using  
Evented Mongrel" line is last, not first in the trace).  Mongrel  
seems to "see" swiftiply when it's running as it runs without  
problems when swiftiply is not.

Any help is highly appreciated.


Kind regards, Niko.