Tech Topics

NEST 1.4 Released

The .NET team within Elasticsearch is happy to announce that NEST and Elasticsearch.NET 1.4 are now available on!

The big theme for this release was Elasticsearch 1.4 parity.

After we released NEST 1.3, we went through all the PR’s that made it into Elasticsearch 1.4 and created tickets for them in our own GitHib issues. Within 2 weeks, all of them were closed!

This means that you can now use the new filters, children and scripted metric aggregations, or call the Get Index API. Check out the 1.4 release notes for the full list.

Stability fixes

Rather than releasing before Christmas, we focused on closing as many of the lingering open tickets and stability fixes as possible.

  • RequestTimeout() now dictates how long ALL calls can take collectively rather than controlling how long each individual call may take. This means that a request timeout of 60 seconds won’t turn into 4 minutes when MaxRetries() is set to 4.
  • @aochsner discovered that when passing a request timeout override for a single request it was ignored.
  • Thrift connection did not respect connect timeout.
  • Thrift connection did not accept new nodes from the SniffingConnectionPool.
  • Some code paths did not keep track of exceptions to be reported back properly.
  • When not using connection pooling we did not respect MaxRetries().

We also heard from many of our users that our default connect timeout of 200ms was a little too stringent on cloud platforms. Our default timeout is now 1s and 2s when using SSL.

Better shield support

NEST 1.3 fully supports all the moving parts of Shield, but we found a bug in our SniffingConnectionPool that would reintroduce newly found nodes as http and not https. If you are planning to use shield and SniffingConnectionPool, upgrading to NEST 1.4 is highly recommended.

We also added a greater default connect timeout when using SSL, which is now set to 2s. We found that connecting locally over SSL is typically fast enough, but when using remote nodes you need some more leeway built in.

Configuring ids in code

An old open issue, long ignored, has finally made it in!

NEST by default infers id‘s on objects when they are not passed explicitly by looking at the Id property of your C# object.

Previously the only way to override this behavior was through the ElasticType attribute:


This change introduced an alternative way to configure id properties, via code:

var settings = new ConnectionSettings()
    .MapIdPropertyFor(o => o.AlternateId);

Observe on backups and restores

Much like ReIndex(), that coordinates several long running/sequential calls and exposes them as an IObservable, we now offer a similar experience for backup and restore:

var interval = TimeSpan.FromMilliseconds(100);
var restoreObservable = this.Client.RestoreObservable(interval, r => r
    .RenamePattern(d + "_(.+)")
    .RenameReplacement(d + "_restored_$1")

In this example we will return an IObservable that you can subscribe allowing you to monitor restore progress and be notified when it completes (or fails).

Many many thanks to Robert Lyson who volunteered to implement this new feature.

.NET 4.5 builds in our NuGet package.

We included specific .NET 4.5 builds of our DLLs in our NuGet package so that you can now use NEST and Elasticsearch on .NET Core applications that target the desktop CLR (KRE-CLR-*). Support for the Core CLR (KRE-CoreCLR-*) is high on our wishlist but since it might mean some breaking changes it won’t be available until we release 2.0.

Our builds now also have source indexing enabled with the help from GitLink. See the pull request for it for details on how to set it up.

Community feedback

Every release blog post we touch on how much we appreciate your contributions, but we really really do! We are pleasantly surprised at the number of you who are on the bleeding edge builds and help us spot errors before they are even released. Andrey Mironoff deserves a special mention here for helping us catch an edge case aggregation parser bug in our bleeding edge builds by providing one of the best reproduce code we’ve ever seen, allowing us to fix the bug within hours.

As always many of our features and bug fixes have been provided by the community, thank you!

If you are developing a .NET application with NEST and you need a fix that has not been released on NuGet yet, remember you can always get our bleeding edge builds from MyGet. Keep in mind, these builds have been unit tested but have not gone through the rigorous integration testing that we do for our NuGet releases against every Elasticsearch 1.x release.

What’s next?

We are going to focus on our 2.0 branch making it the default branch on GitHub as well. develop will go into maintenance mode, keeping track with Elasticsearch updates and 1.x releases.

Our current status-quo means we have 5 different unit/integration tests projects, we have been spiking a unique approach to unify all our testing and documentation needs using Roslyn with something we’ve dubbed literate testing. Much of our efforts in 2.0 will be to re-architect our testing infrastructure.

aspnet50core support will dictate much of our rewrite. The most intrusive issue being that WebRequest is longer available, so we will move to HttpClient as our default IConnection implementation.

We have no plans to drop .NET 4.0 support though!

Another huge part that we hope to tackle in 2.0 is to formalize Elasticsearch’s request and responses and hopefully be able to generate our domain and JSON serialization for optimal performance.

As always, please don’t hesitate to submit your questions/suggestions/issues to either GitHub or StackOverflow.

  • We're hiring

    Work for a global, distributed team where finding someone like you is just a Zoom meeting away. Flexible work with impact? Development opportunities from the start?