Since last couple of months, i see that executing the "bundle install" command for a rails application, source(s) mentioned in gemfile is requested twice when it is supposed to request only once per source mentioned in gemfile.
Can anyone tell me why it is happening and suggest a workaround for it?
In fact bundler does not hit rubygems twice, or at least not for the same reason.
Fetching gem metadata from https://rubygems.org/........
Fetching gem metadata from https://rubygems.org/..
If you look at the queries performed during a "bundle update", here is what you got :
https://rubygems.org:443
http://bundler.rubygems.org/api/v1/dependencies?gems=airbrake,aws-sdk
http://bundler.rubygems.org/api/v1/dependencies?gems=json,activesupport,builder
http://bundler.rubygems.org/api/v1/dependencies?gems=climate_control,rubinius-actor
http://bundler.rubygems.org/api/v1/dependencies?gems=term-ansicolor,gherkin
http://bundler.rubygems.org/api/v1/dependencies?gems=little-plugger,loquacious
http://bundler.rubygems.org/api/v1/dependencies?gems=bones-rcov,bones-rubyforge
http://bundler.rubygems.org/api/v1/dependencies?gems=systemu
http://bundler.rubygems.org/api/v1/dependencies?gems=restclient,spicycode-rcov
I intentionally shortened the URLs for the sake of readability
If you enter this URL in your browser
http://bundler.rubygems.org/api/v1/dependencies.json?gems=airbrake
As you may have noticed, I added the .json extension to have a json output, because the default format is binary
You will see something like this
[
{
"name":"airbrake",
"number":"3.1.8",
"platform":"ruby",
"dependencies":[
["json",">= 0"],
["activesupport",">= 0"],
["builder",">= 0"]
]
},
... (content removed)
]
This response tell us that the airbrake gem depends on json, activesupport and builder. So bundler needs to ask rubygems for more informations about these 3 gems. If you look at the second query above, this is exactly what it does.
http://bundler.rubygems.org/api/v1/dependencies?gems=json,activesupport,builder
This process will take place until all dependencies are resolved. That's why the number of dots may changed depending on the number of "iterations" to resolve all dependencies.
However, I must admit that the reason why the message is shown twice remains unclear. Furthermore, the number of dots (10) does not correspond exactly to the number of queries (9)... I need to investigate a little bit more for that.
Related
We serve some web fonts (.woff) from our static assets and I would like to set the correct mime type (application/x-font-woff). I tried to do this in config/initializers/mime_types.rb but it had no effect:
Mime::Type.register "application/x-font-woff", :woff
The returned mime type still stayed application/octet-stream. I even tried to add this line (because it was the only other place in the rails source where I could find the string "woff"):
Rack::Mime::MIME_TYPES[".woff"] = "application/x-font-woff"
But it still didn't help. How do I properly set the mime type for web fonts?
Until Rack fixes its MIME-type list to a correct woff, the interim hack is indeed your config/initializers/mime_types.rb line:
# tell Rack (and Sprockets) about modern font MIME types:
Rack::Mime::MIME_TYPES['.woff'] = 'application/x-font-woff'
To have it actually take effect, though, you have to wipe tmp/cache and restart your server.
While I also didn't figure out some hack solution to it, I researched this a few days ago (on my rails 3.2 dev server running WEBRick, for reference), and it's Sprockets that sets the bad MIME type on the response, maybe by delegating the choice to Rack, which has a dumb notion of what MIME type to pass for fonts (as of this ravinggenious commit).
I filed a (detailed) ticket on Sprockets and a pull request on Rack, hoping it'd get fixed upstream where it makes the most sense instead, but neither has seen much action yet. I probably should have paid more attention to ttf and eof too, but it was late and I didn't think of it at the time.
(Commenting on either might raise awareness of the problem – one issue is no issue, a people pile is a problem worth fixing? :-)
Moving over from django / python, I am having a little trouble getting the rails logger to log all the information I want. I am wondering how/if the following can be achieved:
Having in the log format(ter) include the specific file, function name and line where the logging statement itself was found. Essentially the equivalent of LOG_MSG_FORMAT = '%(asctime)s %(levelname)s %(filename)s:%(funcName)s(%(lineno)d) : %(message)s' in python logger?
Being able to log all requests, via something similar to a django request logging middleware. Particularly, being able to log the username (if logged in) of every request.
Am I missing something obvious? or does this require (lots of) custom code?
I just found this railtie gem that might help although I imagine it will take some "custom code" to append username to logs. See the Readme section on logging specific controllers and models.
logging-rails railtie
I don't know about getting the file, function, and line number, but it's pretty easy to log from application_controller:
class ApplicationController < ActionController::Base
before_filter :log_user
def log_user
if current_user
Rails.logger.info "Processing Request for #{current_user.name}"
end
end
end
Just to add a quick note in case this is useful for someone:
The lograge gem makes rails logs much similar to django's, plus allows very neat customization, adding parameters such as remote ip address, current_user etc.
It also reduces verbosity of rendered layouts, which I anyway found unnecessary for production. It also plays nicely with logging-rails railtie mentioned by #lukewendling.
Sadly, I still couldn't find anything that shows the file/function/line number like you can easily do with django, but I guess that's just too much to ask.
This is a direct follow-on to this question: What is the fastest way to render json in rails?
My app does a database query and render to JSON for a JS callback. It takes at least 8 seconds for a small (1 MB) dataset, and more like 20 for a large (3.5 MB) one. This is basically going to kill my app as an idea. My users aren't going to put up with this sort of wait.
I've read about multi_json and oj and yajl, and I think I've got them installed, but none of the ways I've tried to activate the various gems in my Gemfile show any improvement in serializing time. How can I prove that I'm using one over the other, so that I compare results between them? I can't find any way of outputting (to the Rails debug log or the JS console in the browser) which library might have gotten used for the actual 'render :json => #data' call.
Instead of fiddling with your controller, a better way is to use the Rails console, like so:
$ rails console
Loading development environment (Rails 3.2.8)
1.8.7 :001 > MultiJson.engine
=> MultiJson::Adapters::JsonGem
You can interact directly with your Rails stack that way.
I finally figured out I could do 'render :text => MultiJson.engine' in my controller. This yielded "MultiJson::Engines::Oj".
It confirms that I'm already using the supposedly fastest JSON library, and I may be hosed. I guess I'll try to return pure text through the controller (which takes 2 seconds compared to 8) and see how fast a routine to convert that to a hash will take...
This is a strange bug that we started seeing about a year ago. At first, I only occasionally noticed it on my dev machine, but now it's been starting to appear in production, which is problematic.
We use Ubuntu (11.04), and Mono 2.6.7 in production (I can also repro with Mono 2.10.x), inside apache, using mod_mono.
Basically, sometimes (very hard to reproduce), when apache starts the application, SolrNet decides to lower case the entire URL it transmits to the solr server. If the application is in this state, it stays this way until it is restarted (and occasionally requires a couple of restarts to clear up.) We might go for 20 - 50 or more restarts without seeing this problem come up. or sometimes it will happen every 2 or 3.
A good url looks like this:
INFO: [] webapp=/solr path=/select params={sort=Creative.PromotionalScore+desc&start=0&q=*:*&?=&qt=standard&fq={!tag%3DCreative.GalleryReviewStatus}Creative.GalleryReviewStatus:Approved&fq={!tag%3DCreative.SectionIncludedTarget}Creative.SectionIncludedTarget:220358+OR+(NOT+Creative.SectionIncludedTarget:[*+TO+*]+*:*)&fq={!tag%3DActive}Active:true&fq={!tag%3DCreative.ShowInGallery}Creative.ShowInGallery:true&fq={!tag%3DCreative.Size}Creative.Size:"Rectangle"&fq={!tag%3DRecordType}RecordType:FiveToOne.Gallery.Rmx.Creative&rows=12}
A bad url looks like this:
http://solrServer:8080/solr/select?qt=standard&fq=%7b!tag%3dcreative.galleryreviewstatus%7dcreative.galleryreviewstatus%3aapproved&fq=%7b!tag%3dcreative.sectionincludedtarget%7dcreative.sectionincludedtarget%3a306433+or+(not+creative.sectionincludedtarget%3a%5b*+to+*%5d+*%3a*)&fq=%7b!tag%3dactive%7dactive%3atrue&fq=%7b!tag%3dcreative.showingallery%7dcreative.showingallery%3atrue&fq=%7b!tag%3dcreative.size%7dcreative.size%3a%22rectangle%22&fq=%7b!tag%3drecordtype%7drecordtype%3afivetoone.gallery.rmx.creative&sort=creative.promotionalscore+desc&rows=18&start=0&q=*%3a*&?
(first, I apologize, these two URLs are extracted from different stages of the pipe, all I have access to at the moment.)
When the bad url is submitted, Solr throws a fatal exception, complaining of an unknown field:
HTTP Status 400 - can not sort on undefined field: creative.promotionalscore
type Status report
message can not sort on undefined field: creative.promotionalscore
description The request sent by the client was syntactically incorrect (can not sort on undefined field: creative.promotionalscore).
Having used Solr and SolrNet in production for four years now, all I can say is that I've never seen this on .NET, so I'm guessing it's a bug in Mono.
In order to pinpoint where exactly the URL is becoming lowercase, I'd put several logging points, for example here, here, and here.
After this logging is in place, once the bug occurs, the log should be analyzed, logging should be probably refined, etc, until the exact source of the bug is located.
Hopefully then the bug can be reproduced, reported, fixed, etc.
I'm writing a book on Rails 3 at the moment and past-me has written in Chapter 3 or so that when a specific feature is run that a routing error is generated. Now, it's unlike me to go writing things that aren't true, so I'm pretty sure this happened once in the past.
I haven't yet been able to duplicate the scenario myself, but I'm pretty confident it's one of the forgotten settings in the environment file.
To duplicate this issue:
Generate a new rails project
important: Remove the public/index.html file
Add cucumber-rails and capybara to the "test" group in your Gemfile
run bundle install
run rails g cucumber:skeleton
Generate a new feature, call it features/creating_projects.feature
Inside this feature put:
This:
Feature: Creating projects
In order to value
As a role
I want feature
Scenario: title
Given I am on the homepage
When you run this feature using bundle exec cucumber features/creating_projects.feature it should fail with a "No route matches /" error, because you didn't define the root route. However, what I and others are seeing is that it doesn't.
Now I've set a setting in test.rb that will get this exception page to show, but I would rather Rails did a hard-raise of the exception so that it showed up in Cucumber as a failing step, like I'm pretty sure it used to, rather than a passing step.
Does anybody know what could have changed since May-ish of last year for Rails to not do this? I'm pretty confident it's some setting in config/environments/test.rb, but for the life of me I cannot figure it out.
After I investigate the Rails source code, it seems like the ActionDispatch::ShowExceptions middleware that responsible of raising exception ActionController::RoutingError is missing in the test environment. Confirmed by running rake middleware and rake middleware RAILS_ENV=test.
You can see that in https://github.com/josh/rack-mount/blob/master/lib/rack/mount/route_set.rb#L152 it's returning X-Cascade => 'pass' header, and it's ActionDispatch::ShowExceptions's responsibility to pick it up (in https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/middleware/show_exceptions.rb#L52)
So the reason you're seeing that your test case is passing because rack-mount is returning "Not Found" text, with status 404.
I'll git blame people and get it fix for you. It's this conditional here: https://github.com/rails/rails/blob/master/railties/lib/rails/application.rb#L159. If the setting is true, the error got translated right but we got error page output. If it's false, then this middleware doesn't get loaded at all. Hold on ...
Update: To clearify the previous block, you're hitting the dead end here. If you're setting action_dispatch.show_exceptions to false, you'll not get that middleware loaded, resulted in the 404 error from rack-mount got rendered. Whereas if you're setting action_dispatch.show_exceptions to true, that middleware will got loaded but it will rescue the error and render a nice "exception" page for you.