Crash while sending document

[clive-devops]

backtrace:

2020-10-30T12:48:46.903895164Z /usr/local/lib/ruby/gems/2.5.0/gems/elasticsearch-transport-7.9.0/lib/elasticsearch/transport/transport/base.rb:309:in `rescue in perform_request': undefined method `host' for nil:NilClass (NoMethodError)
2020-10-30T12:48:46.903928707Z from /usr/local/lib/ruby/gems/2.5.0/gems/elasticsearch-transport-7.9.0/lib/elasticsearch/transport/transport/base.rb:278:in `perform_request'
2020-10-30T12:48:46.903939000Z from /usr/local/lib/ruby/gems/2.5.0/gems/elasticsearch-transport-7.9.0/lib/elasticsearch/transport/transport/http/faraday.rb:37:in `perform_request'
2020-10-30T12:48:46.903948091Z from /usr/local/lib/ruby/gems/2.5.0/gems/elasticsearch-transport-7.9.0/lib/elasticsearch/transport/client.rb:176:in `perform_request'
2020-10-30T12:48:46.903973190Z from /usr/local/lib/ruby/gems/2.5.0/gems/elasticsearch-api-7.9.0/lib/elasticsearch/api/actions/index.rb:73:in `index'

[picandocodigo]

Hi @clive-devops, could you please add a bit more information to the issue?

• Which version of the client are you using?
• What code are you using to instantiate the client?
• What code are you using for index?

Can you connect to the cluster at all? Does client.cluster.health return the cluster state?

[clive-devops]

Hi @picandocodigo

This is an intermittent, during normal runtime, failure.

We're using 7.9.0

We're connecting as follows:

      Elasticsearch::Client.new(
        urls: urls,
        request_timeout: request_timeout,
        reload_connections: true,
        reload_on_failure: true
      )

At this point we're fairly convinced this only arises within threads and that the internal reload mechanism might not be thread safe around the internal connection object(s). We're busy refactoring our code to ensure that new clients are created in isolation within each thread in our own thread pools to determine if that is, in fact, the case.

[clive-devops]

Sorry for the double reply,
worth noting is that we only recently added:

        reload_connections: true,
        reload_on_failure: true

... and it's only since then that we've experienced this error.