Java/kotlin ElasticSearchAsyncClient several issues to check priorities

Hi
Thank you for your support
This is related to Java/Kotlin Client library

I am current using ElasticSearchAsyncClient , Kotlin 7.17.22 with Maven

Can you please answer my below questions ?
I want to know if you have any plan to support below mentioned features

  1. If so, when would be the release ?
  2. If not, Please indicate clearly

#1 and #2 are very important for production stability
I hope you prioritize these
Appreciate your answer

  1. Feature/function accept retrial on failures such as network connection failure or index update failures etc
  1. Reactive API
    It would be great to use reactive API feature such as back pressure considering multiple clients with different capacities and network speed
  1. TypeSafe builders with compatible with Kotlin DSL
    Below link example improves usage and readability greatly
  1. TimeBuilder time unit accepts string in PointInTime
    There must be better way to be type safe and elegant

Thank you

From Elastic Search to Elasticsearch

Added language-clients

Hi @Youngsam_Byun,

Welcome! You raised this topic in the Search rather than Elasticsearch category, so I've moved your request and tagged it with the langauge-clients tag.

I see you've raised the same question as a GitHub issue so just keep an eye out there too. Normally I don't recommend cross-posting thought.

Hope that helps!

Hello! I'll answer to the best of my current knowledge, but these are approximate timings that will probably vary:

  1. We're currently working on updating the underlying Low Level Rest client which will allow us to implement retries. This will hopefully be available in the next major version of the client.
  2. Implementing Reactive API will probably be the next step after the low level client update, but keep in mind that it would only be available for a few suitable endpoints, like the ones mentioned in the issue comments.
  3. There's currently a plan to generate an experimental Kotlin client, but no timeline yet, we'll update the issue as soon as there is any news.
  4. We'll work on fixing it in one of the next minor releases.

Thank you @carly.richmond noted, will do, appreciate it

Thank you very much for your answer @ltrotta
noted well
May I know rough timeline for the next release plan ?
like August .. October etc

The release of the java client is strictly tied to the elasticsearch server releases, and we currently have no timeline for when the next major version will be released. We will keep those github issues updated so that you'll know as soon as we do.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

Adding some more details on these issues:

Retries
Retry policies are often quite application-specific. Although we my add retries for some common errors such connection errors, other errors will require an application-level policy to determine if they should be retried, and how (i.e. delays, number of retries, etc).

Although we may add it in a future release, when and how isn't defined yet. In the meantime, there are a number of well-known retry libraries surch as Spring Retry or Failsafe that can do a great job and offer much more flexibility than what we will ultimately include in the client library.

Reactive API
The Java client comes in two flavors: ElasticsearchClient which is blocking, and ElasticsearchAsyncClient which is asynchronous. A Future can easily be wrapped in a Mono so there's no need for a reactive API for asynchronous calls that return a single result.

Where a reactive API is useful though is for bulk ingestion. The current BulkIngester implements back pressure by blocking callers. A reactive implementation would then be a Subscriber of bulk operations.

The java.util.concurrent.Flow API is only available in Java 9+ while the baseline for the Java client is currently Java 8. In the next major version of the Elastic Stack (currently planned for Q2 2025) we will change the baseline to Java 11, which will unlock a number of features, including a reactive implementation of the Bulk Ingester.

Kotlin
As mentioned, we plan to experiment around a Kotlin client. However, this is just an experiment, and there are no plans for a Kotlin-native client, which would be a significant engineering effort.

That being said, the current Java client can be used in Kotlin in an "almost DSL" way with a with(it) trick. Here's an example showing how to create a search request:

val req = SearchRequest.of { with(it) {
    q("foo")
    from(1)
    pit {
        it.id("bar")
    }
}}

Better time/duration values

This one will lead to breaking changes in the Java client API, and is planned for version 9, unless we find some tricks to avoid breaking the current API.