Using create_unless_exists triggers an infinite loop

[pickypg]

Nothing appears in Elasticsearch while this is running. The index does not already exist there either, nor is there any associated template for it. Running Logstash 1.5RC2.

While trying to debug a different issue, I changed the action to create_unless_exists (json.conf):

input {
  stdin {
    codec => json { }
  }
}

output {
  elasticsearch {
    action => "create_unless_exists"
    host => ["localhost"]
    index => "test-%{+YYYY.MM.dd}"
    protocol => "http"
  }
}

Input (file.json):

{"_id":"ab66c2e6-e641-457c-aa49-7ad87ba680eb","other":"value"}

Running it:

cat file.json | bin/logstash -f json.conf

This endlessly spews the resulting output and CTRL+C can't even get out of it.

Got error to send bulk of actions to elasticsearch server at localhost : [400] {"error":"ActionRequestValidationException[Validation Failed: 1: no requests added;]","status":400} {:level=>:error}
Failed to flush outgoing items {:outgoing_count=>1, :exception=>#<Elasticsearch::Transport::Transport::Errors::BadRequest: [400] {"error":"ActionRequestValidationException[Validation Failed: 1: no requests added;]","status":400}>, :backtrace=>["/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/elasticsearch-transport-1.0.7/lib/elasticsearch/transport/transport/base.rb:132:in `__raise_transport_error'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/elasticsearch-transport-1.0.7/lib/elasticsearch/transport/transport/base.rb:224:in `perform_request'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/elasticsearch-transport-1.0.7/lib/elasticsearch/transport/transport/http/manticore.rb:33:in `perform_request'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/elasticsearch-transport-1.0.7/lib/elasticsearch/transport/client.rb:115:in `perform_request'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/elasticsearch-api-1.0.7/lib/elasticsearch/api/actions/bulk.rb:80:in `bulk'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-0.1.18-java/lib/logstash/outputs/elasticsearch/protocol.rb:82:in `bulk'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-0.1.18-java/lib/logstash/outputs/elasticsearch.rb:413:in `submit'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-0.1.18-java/lib/logstash/outputs/elasticsearch.rb:412:in `submit'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-0.1.18-java/lib/logstash/outputs/elasticsearch.rb:438:in `flush'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-0.1.18-java/lib/logstash/outputs/elasticsearch.rb:436:in `flush'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/stud-0.0.19/lib/stud/buffer.rb:219:in `buffer_flush'", "org/jruby/RubyHash.java:1341:in `each'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/stud-0.0.19/lib/stud/buffer.rb:216:in `buffer_flush'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/vendor/bundle/jruby/1.9/gems/logstash-output-elasticsearch-0.1.18-java/lib/logstash/outputs/elasticsearch.rb:472:in `teardown'", "org/jruby/RubyArray.java:1613:in `each'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/lib/logstash/pipeline.rb:239:in `outputworker'", "org/jruby/RubyArray.java:1613:in `each'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/lib/logstash/pipeline.rb:238:in `outputworker'", "/Users/pickypg/Downloads/logstash-1.5.0.rc2/lib/logstash/pipeline.rb:163:in `start_outputs'"], :level=>:warn}

[talevy]

@pickypg the create_unless_exists action was added to the node protocol. as was done in the original PR: #29.

is there a reason you are using http?

The only way to get around this right now is to LOG the exception as an error (and drop the event), and continue with the pipeline. does that sound good for now?

[pickypg]

@talevy I was trying to figure out was causing a completely unrelated issue, so I just tried it.

At the time, I didn't remember that it only worked on the node protocol (the original approach worked on all of them by adding a check and changing).

The only way to get around this right now is to LOG the exception as an error (and drop the event), and continue with the pipeline. does that sound good for now?

That's fine with me. Anything is better than an infinite, unstoppable loop.

[talevy]

The unfortunate truth is that any exception that is raised within the context of the elasticsearch output plugin will enter an infinite loop. It is the nature of the library Stud::Buffer which is being used.

I will go ahead and make a change for this to log an error and drop message 😞 instead of enter infinite exception world