Logstash 2.2.0 > elasticsearch output connectivity issue

Similar issue here with LogStash 2.2.0, against admittedly older ElasticSearch 1.7.1 - but behind an AWS ELB, with telnet/curl working fine to ElasticSearch (and no issues seen like this with Logstash 1.5.2 or 1.5.4 for months:

{:timestamp=>"2016-02-11T08:04:03.580000+0000", :message=>"elasticsearch-logsink.u_xxxxx_.com:9200 failed to respond", :class=>"Manticore::ClientProtocolException", :backtrace=>["/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/manticore-0.5.2-java/lib/manticore/response.rb:37:in initialize'", "org/jruby/RubyProc.java:281:incall'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/manticore-0.5.2-java/lib/manticore/response.rb:79:in call'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/manticore-0.5.2-java/lib/manticore/response.rb:256:incall_once'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/manticore-0.5.2-java/lib/manticore/response.rb:153:in code'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/elasticsearch-transport-1.0.15/lib/elasticsearch/transport/transport/http/manticore.rb:71:inperform_request'", "org/jruby/RubyProc.java:281:in call'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/elasticsearch-transport-1.0.15/lib/elasticsearch/transport/transport/base.rb:201:inperform_request'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/elasticsearch-transport-1.0.15/lib/elasticsearch/transport/transport/http/manticore.rb:54:in perform_request'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/elasticsearch-transport-1.0.15/lib/elasticsearch/transport/client.rb:125:inperform_request'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/elasticsearch-api-1.0.15/lib/elasticsearch/api/actions/bulk.rb:87:in bulk'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-2.4.1-java/lib/logstash/outputs/elasticsearch/http_client.rb:53:innon_threadsafe_bulk'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-2.4.1-java/lib/logstash/outputs/elasticsearch/http_client.rb:38:in bulk'", "org/jruby/ext/thread/Mutex.java:149:insynchronize'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-2.4.1-java/lib/logstash/outputs/elasticsearch/http_client.rb:38:in bulk'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-2.4.1-java/lib/logstash/outputs/elasticsearch/common.rb:160:insafe_bulk'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-2.4.1-java/lib/logstash/outputs/elasticsearch/common.rb:99:in submit'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-2.4.1-java/lib/logstash/outputs/elasticsearch/common.rb:84:inretrying_submit'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-2.4.1-java/lib/logstash/outputs/elasticsearch/common.rb:28:in multi_receive'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.0-java/lib/logstash/output_delegator.rb:119:inworker_multi_receive'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.0-java/lib/logstash/output_delegator.rb:118:in worker_multi_receive'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.0-java/lib/logstash/output_delegator.rb:65:inmulti_receive'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.0-java/lib/logstash/pipeline.rb:275:in output_batch'", "org/jruby/RubyHash.java:1342:ineach'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.0-java/lib/logstash/pipeline.rb:275:in output_batch'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.0-java/lib/logstash/pipeline.rb:206:inworker_loop'", "/usr/local/NTR/logstash-2.2.0/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.0-java/lib/logstash/pipeline.rb:175:in `start_workers'"], :level=>:warn}

This is running in a Docker 1.8 container, and after this message, the container exists (exit code 137).