Potential throwing of the blocking exception

[AntonLGVS]

In the DefaultReactiveElasticsearch class there is a call to block(). This could potentially cause the IllegalStateException("block()/blockFirst()/blockLast()...) to be thrown. This will be thrown into EventLoop of the Netty Server.
Can make a reactive implementation of the SearchDocumentResponse to remove the blocking call?

[sothawo]

where exactly in which class?

[AntonLGVS]

class ReactiveElasticsearchTemplate:

line 805: Function<SearchDocument, Object> entityCreator = searchDocument -> documentCallback.toEntity(searchDocument)
line 806:     .block();

[sothawo]

I'll have to have a deeper look at this callback, but I think that the reactive version of this callback is not needed here anyway and this could be a non-reactive call.

[AntonLGVS]

Maybe change the callback to a non-reactive version? I can do it.

[sothawo]

The non-reactive code has some callback for this as well, this should be used or consolidated into common code.

[AntonLGVS]

The callback ReadSearchDocumentCallback has a call to the maybeCallAfterConvert public API.
There are solution options:

1. Implementation of the reactive SearchDocumentResponse;
2. Calling the maybeCallAfterConvert method outside the ReadSearchDocumentCallback#toEntity method, but then we need to change the signature of the ReadSearchDocumentCallback#toEntity and return a wrapper with parameters for the maybeCallAfterConvert method. A rough example:

Wrapper wr = toEntity(...);
maybeCallAfterConvert(wr.p1(), wr.p2(),.....);

[sothawo]

I'll hopefully have a look at this deeper in the next days currently I'm quite busy (not doing this as my day job 😃 )

[AntonLGVS]

I'am know that is a free time job. Me too. I have the opportunity to help you develop this project.

[sothawo]

seems the best would be like you suggested to have the SearchDocumentResponse reactive. But this class is currently tied to Elasticsearch classes, so we need to find an abstraction that will work for both the old and new client.

[AntonLGVS]

If you don't mind, i'll take this problem

[sothawo]

that has to be done with the introduction of the new client. I have a branch in my fork where I am working on this; it is planned for the version 4.4 to be able to use either the RestHighLevelClient or the ElasticsearchClient, depending on the configuration. In 5.0 we will then only support the new client.

I can really work on this since Elasticsearch 7.16 is out, since then the new client is fairly stable, before that, there were many changes in packages, structure and functionality.

This also means that we are writing a new reactive template and reactive client as well because we need to use the same request and response classes that the Elasticsearch client uses. For the existing code we had copies/adaptions of code from the Elasticsearch codebase, we need to get rid of that.

So currently I am building a code structure where we for both the imperative and the reactive code we have implementations using the old Elasticsearch libraries and copied code or the new one. In addition to that, that will enable Spring Data Elasticsearch to eventually have other client implementations in the future (OpenSearch might be one).

So this issue with the document callback needs to be addressed in this whole process of restructuring the code. Changing this now in the current code will need refactoring later. So I am not sure where you could currently help here.