Re: Block On File Upload

2011-01-16 Thread Jimmy Thrasher
I wouldn't call it rerouting, but it is likely a response to a TCP transaction. 
Nginx is just a reverse proxy routing requests to the dynos in the first place. 
This is what large scale deployments do anyway, so it's nothing new.

By the way, this is nothing that isn't written on the Heroku docs.. They 
explain it much better than I could.

Hope that helps,

Jimmy

On Jan 15, 2011, at 7:47 PM, John Maxwell jgwmaxw...@gmail.com wrote:

 So the dyno then reroutes requests back to Nginx? really?
 -- 
 You received this message because you are subscribed to the Google Groups 
 Heroku group.
 To post to this group, send email to heroku@googlegroups.com.
 To unsubscribe from this group, send email to 
 heroku+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/heroku?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.



error with bcrypt-ruby (devise required) when deploying on heroku

2011-01-16 Thread Skyporter
Hi everyone,

I'm using devise for user authentication on my webapp. But I have a
problem to deploy my webapp on heroku:  everything work fine in
development, git pushing on heroku working fine, but when I access my
app I have the following error message :

App crashed
This application is temporarily offline.
If you're the administrator of this app, please check your heroku logs
for the backtrace.

heroku logs say:

no such file to load -- bcrypt (LoadError)
- devise/models/database_authenticable.rb line 2

I assume a error with devise and bcrypt in my bundle, nevertheless I
have :

gem 'devise'
gem 'bcrypt-ruby'

when I ran bundle install on dev I had
...
Using bcrypt-ruby (2.1.4)
Using warden (1.0.3)
Using devise (1.2.rc)
...

But bundle on heroku doesn't install gem bcrypt-ruby. I only see
devise, warden (and other gem), but not bcrypt-ruby.

Do you know why ? And how doing a gem install on heroku ? Or how I can
check installed gem (heroku gem list XXX doesn't work) ?

In advance thanks for reading and your reply :)

vincent






-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.



Re: Auto-scaling

2011-01-16 Thread TiagoP
What about auto-scaling for delayed_jobs instead of resque?

On Jan 15, 10:24 pm, John Maxwell jgwmaxw...@gmail.com wrote:
 The Heroku gem itself can do this for you - if you put in a before or
 after_filter a quick check on HTTP_X_HEROKU_QUEUE_DEPTH or 
 HTTP_X_HEROKU_QUEUE_WAIT_TIME
 depending on your criteria, then use the gem to add or remove a dyno as
 suits you.  Look 
 athttp://blog.darkhax.com/2010/07/30/auto-scale-your-resque-workers-on-...for
 inspiration on how to do it.

-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.



Re: Auto-scaling

2011-01-16 Thread John Maxwell
I imagine that the concept would be similar. I don't think DJ supports the 
callbacks that Resque does though - so at the end of each Job you'd need to 
call a method manually to check on what the outstanding depth on the job 
queue is and adjust the workers.

The only problem with DJ is that because it requeues failed jobs for 
retrying then potentially you'd have to take that into account when setting 
the number of workers - query the jobs table to see how many are current 
rather than future, and go off that?

-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.



Re: Block On File Upload

2011-01-16 Thread John Maxwell
Having searched the docs for confirmation on this, there isn't anything 
which explicitly says what the situation is.

However, unless I'm being a plonker, which is possible - then nginx only 
reroutes the request to the dyno once the request is complete - ie the file 
has been received. Otherwise you'd be streaming data into the dyno, which is 
not how file uploads work! The dyno would obviously be blocked whilst 
processing the upload, and transferring to S3 unless you do that in the 
background, but actually uploading itself shouldn't block it, surely?

-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.



Re: Block On File Upload

2011-01-16 Thread John Beynon
there's a bit at the bottom of this page http://docs.heroku.com/s3 that may 
give an additional clue

This is the preferred approach if you’re working with file uploads bigger 
than 4mbs. The idea is to skip the hop on your application dyno, making a 
connection from the end user browser straight to S3.

John.

-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.



Re: Block On File Upload

2011-01-16 Thread John Maxwell
Yeah - that is talking about the outgoing hop to S3 from Heroku - which is a 
blocking I/O, not the incoming step into Nginx... Any word on this from an 
official source?

-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.



Re: Block On File Upload

2011-01-16 Thread Oren Teich
A dyno is the entire stack.  A request, the second it hits Heroku,
blocks a dyno.  This could be because your application is processing,
or because you are handling an upload.

If you are doing decent size upload, you should have your app upload
directly to S3.

Oren

On Sun, Jan 16, 2011 at 12:33 PM, John Maxwell jgwmaxw...@gmail.com wrote:
 Yeah - that is talking about the outgoing hop to S3 from Heroku - which is a
 blocking I/O, not the incoming step into Nginx... Any word on this from an
 official source?

 --
 You received this message because you are subscribed to the Google Groups
 Heroku group.
 To post to this group, send email to heroku@googlegroups.com.
 To unsubscribe from this group, send email to
 heroku+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/heroku?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.



Re: Block On File Upload

2011-01-16 Thread John Maxwell
Right, that's more of a limitation that I thought apologies for being wrong 
(and sure I wasn't!) - I'm not massively familiar with Rack, but could you 
use a Rack Middleware to detect a file upload and spin up another dyno 
whilst it is in progress? Or is that not detectable within Rack?

-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.



Re: 'no such file -- json' during 'heroku rake db:migrate'

2011-01-16 Thread Server Çimen
Adding
gem 'json_pure'
to Gemfile worked for me in a similar case.

On 4 Ocak, 21:57, Sam sam.grossb...@gmail.com wrote:
 I added the Koala gem to my bundle, which has a dependency on the json
 gem.  I've also explicitly added the json gem to my bundle to make
 sure that isn't somehow the problem.  I've made sure I've uploaded
 both Gemfile and Gemfile.lock.  I don't get any errors when I push.
 Here's the trace:

 rake aborted!
 no such file to load -- json
 /disk1/home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-
 ee90b3447615/mnt/.bundle/gems/ruby/1.8
 /gems/koala-0.10.0/lib/koala.rb:6:in `require'
 /disk1/home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-
 ee90b3447615/mnt/.bundle/gems/ruby/1.8
 /gems/koala-0.10.0/lib/koala.rb:6
 /usr/ruby1.8.7/lib/ruby/gems/1.8/gems/bundler-1.0.3/lib/bundler/
 runtime.rb:64:in `require'
 /usr/ruby1.8.7/lib/ruby/gems/1.8/gems/bundler-1.0.3/lib/bundler/
 runtime.rb:64:in `require'
 /usr/ruby1.8.7/lib/ruby/gems/1.8/gems/bundler-1.0.3/lib/bundler/
 runtime.rb:62:in `each'
 /usr/ruby1.8.7/lib/ruby/gems/1.8/gems/bundler-1.0.3/lib/bundler/
 runtime.rb:62:in `require'
 /usr/ruby1.8.7/lib/ruby/gems/1.8/gems/bundler-1.0.3/lib/bundler/
 runtime.rb:51:in `each'
 /usr/ruby1.8.7/lib/ruby/gems/1.8/gems/bundler-1.0.3/lib/bundler/
 runtime.rb:51:in `require'
 /usr/ruby1.8.7/lib/ruby/gems/1.8/gems/bundler-1.0.3/lib/bundler.rb:
 112:in `require'
 /disk1/home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-
 ee90b3447615/mnt/config/application.rb
 :7
 /usr/ruby1.8.7/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
 `gem_original_require'
 /usr/ruby1.8.7/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
 `require'
 /disk1/home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-
 ee90b3447615/mnt/Rakefile:4
 /home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-ee90b3447615/
 mnt/.bundle/gems/ruby/1.8/gems/
 rake-0.8.7/lib/rake.rb:2383:in `load'
 /home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-ee90b3447615/
 mnt/.bundle/gems/ruby/1.8/gems/
 rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile'
 /home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-ee90b3447615/
 mnt/.bundle/gems/ruby/1.8/gems/
 rake-0.8.7/lib/rake.rb:2017:in `load_rakefile'
 /home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-ee90b3447615/
 mnt/.bundle/gems/ruby/1.8/gems/
 rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
 /home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-ee90b3447615/
 mnt/.bundle/gems/ruby/1.8/gems/
 rake-0.8.7/lib/rake.rb:2016:in `load_rakefile'
 /home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-ee90b3447615/
 mnt/.bundle/gems/ruby/1.8/gems/
 rake-0.8.7/lib/rake.rb:2000:in `run'
 /home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-ee90b3447615/
 mnt/.bundle/gems/ruby/1.8/gems/
 rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
 /home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-ee90b3447615/
 mnt/.bundle/gems/ruby/1.8/gems/
 rake-0.8.7/lib/rake.rb:1998:in `run'
 /home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-ee90b3447615/
 mnt/.bundle/gems/ruby/1.8/gems/
 rake-0.8.7/bin/rake:31
 /usr/ruby1.8.7/bin/rake:19:in `load'
 /usr/ruby1.8.7/bin/rake:19
 (in /disk1/home/slugs/387534_a0b1a59_ad78-aeb0c56d-3e90-425c-aa07-
 ee90b3447615/mnt)

-- 
You received this message because you are subscribed to the Google Groups 
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.