Skip to content
View gist:ef2f8d7732d87d7eb9ed
<core name="catalyst" instanceDir="catalyst" >
<property name="enable.searcher" value="true" />
<property name="enable.master" value="true" />
View gist:a73eb6a8b6289e59d64d
| Debug
Please submit text block below with your ticket to Fastly
View gist:053a54c82a970da6d810
<title>Fastly Debug App</title>
* { box-sizing: border-box; }
body {
font-size: 12px;
font-family: 'Helvetica Neue', helvetica, sans-serif;
View gist:4864c69a33ba605e72da
Class Something
attr_accessor :foo
something =
something.respond_to?(:foo) # => true
something.respond_to?(:foo=) # => true
something.respond_to?(:bar) # => false
View gist:22ee1b97a3cb581f9138
to_field "something" do |record, accumulator|
leader = record.leader
# The only reason you want the leader is becuase you are going to do
# SOMETHING with it, right? You're not just gonna index the leader, are ya?
output = do_something_to(leader)
accumulator << output
View gist:488d4c5e63677038149d

Thread Pools

A Thread Pool is an abstraction that you can give a unit of work to, and the work will be executed by one of possibly several threads in the pool. One motivation for using thread pools is the overhead of creating and destroying threads. Creating a pool of reusable worker threads then repeatedly re-using threads from the pool can have huge performace benefits for a long-running application like a service.

concurrent-ruby also offers some higher level abstractions than thread pools. For many problems, you will be better served by using one of these -- if you are thinking of using a thread pool, we especially recommend you look at and understand Futures before deciding to use thread pools directly instead. Futures are implemented using thread pools, but offer a higher level abstraction.

But there are some problems for which directly using a thread pool is an appropriate solution. Or, you may wish to make your own thread pool to run Futures on, to be separate or have different characterist

View gist:12e3479c63a76d78b8ae
<container xmlns:foo="http://one">
<container xmlns:foo="http://two">
View gist:901138fb10b666918244
^Crake aborted!
/Users/jrochkind/.gem/ruby/1.9.3/gems/activesupport-4.0.4/lib/active_support/core_ext/kernel/agnostics.rb:7:in ``'
/Users/jrochkind/.gem/ruby/1.9.3/gems/activesupport-4.0.4/lib/active_support/core_ext/kernel/agnostics.rb:7:in ``'
/Users/jrochkind/.gem/ruby/1.9.3/bundler/gems/blacklight_marc-3959de95eb3f/lib/railties/solr_marc.rake:37:in `block (4 levels) in <top (required)>'
/Users/jrochkind/.gem/ruby/1.9.3/bundler/gems/blacklight_marc-3959de95eb3f/lib/railties/solr_marc.rake:20:in `block (3 levels) in <top (required)>'
Tasks: TOP => solr:marc:index:work
(See full trace by running task with --trace)
Error running fixtures
D, [2014-08-26T14:48:18.070539 #12386] DEBUG -- : Instance stop method called for pid '12397'
View gist:c6bb024f105453865a8e
NFO [main] ( - Adding 30 of 30 documents to index
INFO [main] ( - Deleting 0 documents from index
INFO [main] ( - Calling commit (with optimize set to false)
Aug 26, 2014 2:41:00 PM org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner run
WARNING: A problem has occured exiting runner org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner@bdccedd
org.apache.solr.common.SolrException: Not Found
Not Found
View gist:59b6330e3f52710cc49e
# Monkey patch to ActiveRecord to prevent 'implicit' checkouts. Currently tested with Rails 4.0.8, prob
# should work fine in Rails 4.1 too.
# If you create a thread yourself, if it uses ActiveRecord objects without
# explicitly checking out a connection, one will still be checked out implicitly.
# If it is never checked back in with `ActiveRecord::Base.clear_active_connections!`,
# then it will be leaked.
Something went wrong with that request. Please try again.