View gist:a73eb6a8b6289e59d64d
1 2 3
| Debug
Please submit text block below with your ticket to Fastly
ewogICJnZW9pcCI6IHsKICAgICJjaSI6ICJCYWx0aW1vcmUiLAogICAgInN0IjogIk1EIiwKICAgICJjdCI6ICJVbml0ZWQgU3RhdGVzIiwKICAgICJjbyI6ICJOQSIKICB9LAogICJwb3BMYXRlbmN5IjogewogICAgImRmdyI6IDM2LAogICAgImRlbiI6IDQ2LAogICAgIm9yZCI6IDIxLAogICAgImlhZCI6IDQsCiAgICAiYXRsIjogMTYsCiAgICAiamZrIjogOCwKICAgICJtaWEiOiAyOSwKICAgICJsYXgiOiA2NywKICAgICJzamMiOiA4MCwKICAgICJzZWEiOiA3NQogIH0sCiAgInBvcEFzc2lnbm1lbnRzIjogewogICAgImFjIjogImlhZCIsCiAgICAiYXMiOiAiaWFkIiwKICAgICJkeSI6ICJhdGwiCiAgfSwKICAicmVxdWVzdCI6IHsKICAgICJ0aW1lIjogIjIwMTUtMDQtMTRUMjE6MjY6MTIuMDAwWiIsCiAgICAiaG9zdCI6ICJ3d3cuZmFzdGx5LWRlYnVnLmNvbSIsCiAgICAiYWNjZXB0IjogInRleHQvaHRtbCxhcHBsaWNhdGlvbi94aHRtbCt4bWwsYXBwbGljYXRpb24veG1sO3E9MC45LGltYWdlL3dlYnAsKi8qO3E9MC44IiwKICAgICJ1c2VyYWdlbnQiOiAiTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfOF81KSBBcHBsZVdlYktpdC81MzcuMzYgKEtIVE1MLCBsaWtlIEdlY2tvKSBDaHJvbWUvNDEuMC4yMjcyLjExOCBTYWZhcmkvNTM3LjM2IiwKICAgICJhY2NlcHRsYW5ndWFnZSI6ICJlbi1VUyxlbjtxPTAuOCIsCiAgICAiY
View gist:053a54c82a970da6d810
1 2 3 4 5 6 7 8 9 10
 
<html>
<head>
<title>Fastly Debug App</title>
<style>
* { box-sizing: border-box; }
body {
font-size: 12px;
font-family: 'Helvetica Neue', helvetica, sans-serif;
View gist:4864c69a33ba605e72da
1 2 3 4 5 6 7 8
Class Something
attr_accessor :foo
end
 
something = Something.new
something.respond_to?(:foo) # => true
something.respond_to?(:foo=) # => true
something.respond_to?(:bar) # => false
View gist:22ee1b97a3cb581f9138
1 2 3 4 5 6 7 8 9
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
end
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
1 2 3 4 5 6 7 8
<doc>
<container xmlns:foo="http://one">
<foo:node>
</container>
<container xmlns:foo="http://two">
<foo:node>
</container>
</doc>
View gist:901138fb10b666918244
1 2 3 4 5 6 7 8 9 10
^Crake aborted!
Interrupt:
/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
1 2 3 4 5 6 7 8 9 10
NFO [main] (MarcImporter.java:582) - Adding 30 of 30 documents to index
INFO [main] (MarcImporter.java:583) - Deleting 0 documents from index
INFO [main] (MarcImporter.java:456) - 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
 
request: http://127.0.0.1:8888/solr/update?wt=xml&version=2.2
View gist:59b6330e3f52710cc49e
1 2 3 4 5 6 7 8 9 10
######################
#
# 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.
#
View gist:fe7e4881b9198285d08e
1 2 3 4 5 6 7 8 9 10
GEM
remote: https://rubygems.org/
specs:
actionmailer (4.0.8)
actionpack (= 4.0.8)
mail (~> 2.5.4)
actionpack (4.0.8)
activesupport (= 4.0.8)
builder (~> 3.1.0)
erubis (~> 2.7.0)
Something went wrong with that request. Please try again.