# Java/kotlin ElasticSearchAsyncClient several issues to check priorities **URL:** \ **Category:** Elasticsearch\ **Tags:** language-clients\ **Created:** [July 15, 2024, 7:28am UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123 "2024-07-15T07:28:28Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Youngsam\_Byun](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/youngsam_byun/32/136033_2.png) [@Youngsam\_Byun](https://discuss.elastic.co/u/Youngsam_Byun)\ **Post date:** [July 15, 2024, 7:28am UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/1 "2024-07-15T07:28:28Z")
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 > > > \### Description > > Hi, > > I am wondering if there are any plans for the new clie…nt to support the retrying of requests on failure? > > I noticed when searching for this that some of the other clients seem to have this functionality: > \- \[.net\](https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/retries.html) > \- \[php\](https://www.elastic.co/guide/en/elasticsearch/client/php-api/current/set-retries.html) > \- \[ruby\](https://www.elastic.co/guide/en/elasticsearch/client/ruby-api/current/basic-config.html) > > For the previous RestHighLevelClient I have built my own retry mechanism and I am wondering if I should do the same for the new client? > > One of the 'issues' I have run into when looking into implementing this mechanism myself was the fact that the client only throws a generic \`ElasticsearchException\` with \`ErrorResponse\`. Making the error handling a bit annoying to work with since most Java retry libraries depend on usage of exceptions types to determine if you want to conditionally retry a request or not. > > An option would be to re-create and throw exceptions based on the \`ErrorResponse\` for the retry-able errors, or just implement the retry system myself completely without a library. But I first want to check in here before I go down that route. > > I'd be willing to contribute, even though I'd have to get familiar with the codebase first. > > Thanks in advance! 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 > > > \### Description > > Hello Elastic team, > > I wanted to reach out asking for a possi…ble enhancement request please. > This elasticsearch-java project proposes a blocking api. Adding to that it proposes async api. Those two are already great, many thanks. > > However, it is currently lacking a reactive api, just to clarify, async does not mean reactive. > > Many applications nowadays are reactive (not just async). > > Would it be possible to enrich this project with reactive api which respects the reactive manifesto please? 1. TypeSafe builders with compatible with Kotlin DSL Below link example improves usage and readability greatly > > > \## 🚀 Feature Proposal > > The \[Elasticsearch Specification \](https://github.com/e…lastic/elasticsearch-specification) could be used to generate a Kotlin DSL that can be used with the Elasticsearch Java client's builders. > > Alternatively, one could do the same thing directly in Kotlin using fully Kotlin-based builders. > > \## Motivation > > I'm writing a lot of Elasticsearch client code in Kotlin and was getting tired of how hard it was to read with complex queries, even with the builder - > > \`\`\` kotlin > fun getMyValues() : Deferred\\> = > client.search( { \_0 -\> > \_0.index("my\_index") > .size(0) > .query { \_1 -\> > \_1.bool { \_2 -\> > \_2.filter { \_3 -\> > \_3.term { \_4 -\> > \_4.field("origin") > .value { \_5 -\> > \_5.stringValue("Skywalker Ranch") > } > } > }.filter { \_3 -\> > \_3.term { \_4 -\> > \_4.field("destination") > .value { \_5 -\> > \_5.stringValue("Narnia") > } > } > }.filter { \_3 -\> > \_3.range { \_4 -\> > \_4.field("startDate") > .gte(JsonData.of("now-14d/d")) > .lte(JsonData.of("now/d")) > } > } > } > }.aggregations("avgCost") { \_2 -\> > \_2.avg { \_3 -\> > \_3.field("cost") > } > }.aggregations("uniqueUsers") { \_2 -\> > \_2.cardinality { \_3 -\> > \_3.field("userId") > } > } > }, MyDoc::class.java).asDeferred() > \`\`\` > > Kotlin is great at this kind of thing, so I gave a try at manually implementing it and started to wonder if it could be automated. The easier it is to describe a query in Elasticsearch, the more I can do with the technology. > > \## Example > > The DSL could vastly improve ease of use in Kotlin projects. Here's one sample of some easy to work with DSL code that I successfully implemented as a proof of concept: > > \`\`\` kotlin > val searchResponse: CompletableFuture\ = client.search { > index("my\_index") > size(0) > query { > bool { > filter { > term("origin", "Skywalker Ranch") > term("destination", "Narnia") > range("startDate") { > gte("now-14d/d") > lt("now/d") > } > } > } > } > aggregations { > "date\_ranges".dateRange("startDate") { > range("1Wk") { > from("now-7d/d") > to("now/d") > } > range("2Wk") { > from("now-14d/d") > to("now-7d/d") > } > aggregations { > "avgCost".avg("cost") > "uniqueUsers".cardinality("userId") > } > } > } > } > \`\`\` > > We can use an inline reified function for searches to 1) avoid having to indicate the class twice and 2) invoke the SearchKt object and build our \`SearchRequest\`. > > \`\`\` kotlin > inline fun \ ElasticsearchAsyncClient.search(setup: SearchKt.() -\> Unit): CompletableFuture\\> = > this.search(SearchKt().apply(setup).build(), T::class.java) > \`\`\` > > All one needs to do to make the above functionality possible is for to auto-generate various Kotlin builders on top of the existing Java-based ones (or, alternatively, set them up without Java at all) - something that might look like this: > > \`\`\` kotlin > // See https://kotlinlang.org/docs/type-safe-builders.html#scope-control-dslmarker > @DslMarker > annotation class ElasticMarker > > // Incomplete list of functionality that SearchRequest.Builder supports > @ElasticMarker > class SearchKt { > private val builder = SearchRequest.Builder() > > fun build(): SearchRequest = builder.build() > > fun index(value: String, vararg values: String) { > builder.index(value, \*values) > } > fun size(value: Int) { > builder.size(value) > } > fun query(setup: QueryKt.() -\> Unit) { > builder.query(QueryKt().apply(setup).build()) > } > fun aggregations(setup: AggregationsKt.() -\> Unit) { > builder.aggregations(AggregationsKt().apply(setup).build()) > } > } > \`\`\` 1. TimeBuilder time unit accepts string in PointInTime There must be better way to be type safe and elegant > > > I am trying to create a point-in-time (code is in Kotlin) > \`\`\`kotlin > client.ope…nPointInTime { builder -\> > builder.index(index) > .keepAlive { timeBuilder -\> timeBuilder.time("5m") } > } > \`\`\` > As can be seen, I have to specify the time and the unit as part of a string. This is neither very elegant nor type safe. Is this currently the only way to set these time values or am I missing something? > > The old high-level client accepted a TimeValue, which was both a long and an associated TimeUnit. However, while the new client seems to also have \[TimeUnit\](https://github.com/elastic/elasticsearch-java/blob/main/java-client/src/main/java/co/elastic/clients/elasticsearch/\_types/TimeUnit.java) class, it seems to be entirely disconnected from the \[Time\](https://github.com/elastic/elasticsearch-java/blob/main/java-client/src/main/java/co/elastic/clients/elasticsearch/\_types/Time.java) class. > The only usage of TimeUnit I can find is in the \[DiskUsageRequest\](https://github.com/elastic/elasticsearch-java/blob/main/java-client/src/main/java/co/elastic/clients/elasticsearch/indices/DiskUsageRequest.java), but it seems to be used incorrectly there (TimeUnit does not contain a duration, but it tries to parse the timeout duration as a TimeUnit). > > I also found a \[TimeBuilders\](https://github.com/elastic/elasticsearch-java/blob/main/java-client/src/main/java/co/elastic/clients/elasticsearch/\_types/TimeBuilders.java) class in the same package, but it is empty. Thank you ---
**Author:** ![carly.richmond](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/carly.richmond/32/104935_2.png) [@carly.richmond](https://discuss.elastic.co/u/carly.richmond)\ **Post date:** [July 15, 2024, 2:09pm UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/2 "2024-07-15T14:09:05Z")
From #Elastic Search to #Elasticsearch ---
**Author:** ![carly.richmond](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/carly.richmond/32/104935_2.png) [@carly.richmond](https://discuss.elastic.co/u/carly.richmond)\ **Post date:** [July 15, 2024, 2:09pm UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/3 "2024-07-15T14:09:06Z")
Added #language-clients ---
**Author:** ![carly.richmond](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/carly.richmond/32/104935_2.png) [@carly.richmond](https://discuss.elastic.co/u/carly.richmond)\ **Post date:** [July 15, 2024, 2:17pm UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/4 "2024-07-15T14:17:31Z")
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](https://github.com/elastic/elasticsearch-java/issues/845) so just keep an eye out there too. Normally I don't recommend cross-posting thought. Hope that helps! ---
**Author:** ![ltrotta](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ltrotta/32/124003_2.png) [@ltrotta](https://discuss.elastic.co/u/ltrotta)\ **Post date:** [July 15, 2024, 2:59pm UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/5 "2024-07-15T14:59:56Z")
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. ---
**Author:** ![Youngsam\_Byun](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/youngsam_byun/32/136033_2.png) [@Youngsam\_Byun](https://discuss.elastic.co/u/Youngsam_Byun)\ **Post date:** [July 15, 2024, 3:39pm UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/6 "2024-07-15T15:39:45Z")
Thank you @carly.richmond noted, will do, appreciate it ---
**Author:** ![Youngsam\_Byun](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/youngsam_byun/32/136033_2.png) [@Youngsam\_Byun](https://discuss.elastic.co/u/Youngsam_Byun)\ **Post date:** [July 15, 2024, 3:40pm UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/7 "2024-07-15T15:40:56Z")
Thank you very much for your answer @ltrotta noted well May I know rough timeline for the next release plan ? like August .. October etc ---
**Author:** ![ltrotta](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ltrotta/32/124003_2.png) [@ltrotta](https://discuss.elastic.co/u/ltrotta)\ **Post date:** [July 15, 2024, 4:25pm UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/8 "2024-07-15T16:25:22Z")
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. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [August 12, 2024, 4:26pm UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/9 "2024-08-12T16:26:02Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed. ---
**Author:** ![swallez](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/swallez/32/11972_2.png) [@swallez](https://discuss.elastic.co/u/swallez)\ **Post date:** [August 28, 2024, 1:00pm UTC](https://discuss.elastic.co/t/java-kotlin-elasticsearchasyncclient-several-issues-to-check-priorities/363123/10 "2024-08-28T13:00:54Z")
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](https://github.com/spring-projects/spring-retry) or [Failsafe](https://failsafe.dev/) 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: ```kotlin 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.