[deadbadger]

Getting continuous errors on deploy during the bundle stage like so:

  /usr/lib/ruby/1.9.1/rubygems/remote_fetcher.rb:215:in `fetch_http': bad response Not Found 404 (http://bb-m.rubygems.org/quick/Marshal.4.8/activesupport-3.2.11.gemspec.rz)

Is this because rubygems.org is being nailed?

[outside1234]

seems to be - mine is stuck at getting metadata from rubygems.org for 45 minutes. is there an alternative server to fetch this from?

[amalag]

For a less hammered server, can use http://bundler-api.herokuapp.com

I usually just use that one for my apps, much faster than rubygems.org

[steveklabnik]

It's been an hour, but you could also fetch straight from github with this in your Gemfile:

   gem "rails", :github => "rails/rails", :tag => 'v3.2.11'

[qrush]

This is a mirror, so that's why it's probably out of date...can you try just production.cf.rubygems.org ? I have heard zero reports of downtime or other issues. :/

http://uptime.rubygems.org/131647

[deadbadger]

Hi - thanks for responding. My deploy's gone through now, but I'm curious how I ended up contacting a mirror - I was running the default bundler capistrano task, so (approx):

  $ cd <deploy-path> && bundle install --gemfile Gemfile --path <shared-path>/bundle --without development test

I haven't deliberately pointed anything at a mirror - do you have any idea how might my install have ended up doing so? This is with rubygems 1.8.11, bundler 1.0.21.

[spatten]

I'm getting exactly the same thing. Glad to know it's not just me.

[deadbadger]

For the time being I've rolled back the gem changes and applied the suggested hotfix (removing XML from the default params parsers). I've been trying for a solid hour to get a deploy out with the updated rails version, and it's just not having any of it.

Edit: finally got it out. This deploy model is completely screwed, though. It just shouldn't be normal to have a service like rubygems.org in the daily deploy loop. This is absolutely not a knock on the fantastic volunteers that run it - they simply shouldn't be dealing with this sort of load spike.