CODEWITHSUNDEEP
elasticsearch
anti tech
anti tech

Reputation: 33

Resulting all the indices while trying to get only those indices which are associated with specific alias

I have recently upgraded application from Elastic search 5.3.1 to 6.0.

My requirement was to get all the indices which were associated with specific alias.

I used below mentioned snippet to fetch all indices associated with specific alias . This snippet is working fine in 5.3.1 and giving only those indices which are associated with that specific alias.

GetAliasesResponse r = client.admin().indices().getAliases(new 
GetAliasesRequest("givenalias")).actionGet();

But after ES 6.0 , the same snippet giving all the indices which are created in system .

Ideally it should only return those indices which are associated with given alias .Not others. This was working in Elastic search 5.3.1.

Upvotes: 1

Views: 1249

Answers (1)

Nikolay Vasiliev
Nikolay Vasiliev

Reputation: 6066

TL;DR: It is an intended breaking change in the Java API of Elasticsearch (though it is not explicitly mentioned in the "Breaking changes in 6.0 » Java API changes" page).

The following is the story of discovering this fact. (Note: the original answer was heavily edited, hence comments might be out of date.)

Breaking changes in the REST API in 6.0

First I noticed that this part of the REST API changed in Elasticsearch 6.0. There are two reported breaking changes concerning aliases:

Though there isn't mentioned anything concerning OP's case.

From what I have seen doing queries, this query works in Elasticsearch 5:

GET /alias1/_aliases

And does not work in Elasticsearch 6, giving the following error:

{
  "error": "Incorrect HTTP method for uri [/alias1/_aliases] and method [GET], allowed: [PUT]",
  "status": 405
}

Interestingly, GET /alias1/_alias works in both versions and returns same result.

Moreover, I didn't manage to find an example of GET /alias1/_aliases in the documentation of nor 5.6, neither 6.0.

Reproducing the bug

After having realised that OP is actually using the Java API, I managed to reproduce the exact same behavior.

The following code:

GetAliasesResponse alias1 = client.admin().indices()
    .getAliases(new GetAliasesRequest("alias1")).actionGet();

In ES 5 produces this in the IntelliJ debugger:

GetAliasesResponse in ES 5

And for ES 6 I've got the following:

GetAliasesResponse in ES 6

As you can see, there are extra keys in the second output, which have empty values.

Diving into the source code

Quick search over the elasticsearch codebase gave me the final explanation. In ES 5 there was a test testIndicesGetAliases which was checking that list of indices returned for a test alias has exactly one element (IndexAliasesIT.java#L554):

    logger.info("--> getting alias1");
    GetAliasesResponse getResponse = admin().indices().prepareGetAliases("alias1").get();
    assertThat(getResponse, notNullValue());
    assertThat(getResponse.getAliases().size(), equalTo(1));

And in 6.0 it checks that the size is 5! (IndexAliasesIT.java#L573)

    logger.info("--> getting alias1");
    GetAliasesResponse getResponse = admin().indices().prepareGetAliases("alias1").get();
    assertThat(getResponse, notNullValue());
    assertThat(getResponse.getAliases().size(), equalTo(5));

This change was introduced in this commit, which is related to these issues:

This is actually interesting, because one of the reported REST API breaking changes that we have see above also broke compatibility of some Java API calls.

What you can do

In short term, you need just to filter out those keys with empty values.

In longer term I think it makes sense to migrate to Java High Level REST Client since Elastic plan to deprecate the TransportClient in version 7.0:

We plan on deprecating the TransportClient in Elasticsearch 7.0 and removing it completely in 8.0. Instead, you should be using the Java High Level REST Client, which executes HTTP requests rather than serialized Java requests.

In general, Elasticsearch breaks compatibility quite often, so it's better to stay away from the dark corners of it like Java API.

Thanks for reading.

Hope that helps!

Upvotes: 1

Related Questions