client.transport.reload_connections! creates new connections but doesn't reap old connections

[vlaadbrain]

reload_connections! doesn't "reload" connections, it just builds new ones!. which will lead to file description consumption.

[karmi]

My assumption was that the connection will be closed eventually, as Faraday doesn't have any close method. I guess it could be handled on the specific adapter level. I'll look into that.

[karmi]

@vlaadbrain What HTTP adapter (gem) have you been using, by the way?

[vlaadbrain]

I'm using manticore, through - logstash-output-elasticsearch (2.1.2), i have sniffing enabled in the plugin, which calls reload_connections! in a loop

[caclifton]

I also have this issue using logstash 2.1.0-1 on ubuntu 12.04.3 LTS with the ES plugin. Someone should consider changing the documentation to alert users of this until it's fixed.

[karmi]

We're looking into the issue with @jsvd and will post some info soon, thanks for keep reporting this, everybody!

[jsvd]

Fixing this requires two changes, one in manticore and another in elasticsearch-ruby's manticore transport:

1. currently manticore doesn't expose a way to clear resources associated with a Manticore::Client: opened issue for this Add a Manticore::Client#close method to free resources cheald/manticore#38
2. once this functionality is exposed in Manticore the manticore transport in elasticsearch-ruby can call client.close during __rebuild_connections: https://github.com/elastic/elasticsearch-ruby/blob/master/elasticsearch-transport/lib/elasticsearch/transport/transport/base.rb#L96-L100

@karmi my idea is that, in Transport::Base, __rebuild_connections will call a new method __close_connections which is a no-op by default. Manticore transport will implement this according to 1. WDYT?

[karmi]

@jsvd Yes, let's implement __close_connections in the base class, allowing every adapter to implement it, thanks!