I was recently developing a microservice via quarkus with the new hibernate search extension. Hibernate search is working great thanks to all the contributors.
I wanted to include tracing functionality with opentracing-contrib/java-elasticsearch-client yet i could not find a way to initialize the elasticsearch RestClient in hibernate search.
I explicitly created the client as the client and was able to observe the trace to elasticsearch cluster such as;
There is a way to configure the underlying HTTP client. Be aware this is SPI, to it’s intended for integrators and may change in backward-incompatible ways, more often than APIs (e.g. in minor versions).
public class MyBeanConfigurer implements BeanConfigurer {
@Override
public void configure(BeanConfigurationContext context) {
context.assignRole(
ElasticsearchHttpClientConfigurer.class,
BeanReference.of( MyClientConfigurer.class )
);
}
}
Register your bean configurer by adding a file named META-INF/services/org.hibernate.search.engine.environment.bean.spi.BeanConfigurer to your resources, containing a single line with the fully-qualified class name of MyBeanConfigurer (e.g. com.mycompany.MyBeanConfigurer).
You can have a look at the code of the AWS integration for an example: it needs to change the HTTP client configuration as well.
I understand better now how to create custom beans. However, I am still having some difficulties.
I tried the following and made MyBeanConfigurer class and added it into resources/META-INF/services/org.hibernate.search.engine.environment.bean.spi.BeanConfigurer
public class MyElasticsearchHttpClientConfigurer implements ElasticsearchHttpClientConfigurer {
@Override
public void configure(HttpAsyncClientBuilder httpAsyncClientBuilder, ConfigurationPropertySource configurationPropertySource) {
RestClientBuilder.HttpClientConfigCallback httpClientConfigCallback = new TracingHttpClientConfigCallback(new QuarkusJaegerTracer());
httpClientConfigCallback.customizeHttpClient(httpAsyncClientBuilder);
}
}
However still was not able to get the traces.
Also, I am not completely sure this is the correct way to add a RestClientBuilder.HttpClientConfigCallback to the httpAsyncClientBuilder. Do you think I am doing this incorrect?
First step would be to put a breakpoint in your new class, and launch the application in debug mode to check that it’s correctly being detected. If it’s not, your new resource file may be missing from your JAR?
The snippet of code you showed looks good.
That being said, I don’t know where the tracer gets its information from, but if it relies on thread locals to store then fetch context, then it definitely won’t work. Elasticsearch requests are processed and sent from dedicated thread pools, not from application threads. That might explain why you’re not getting any trace?
Hi @gsmet are you saying the service file won’t be added for native specifically or in JVM mode as well.
@yrodiere I added a breakpoint and launched the application yet still was not able to detect MyElasticsearchHttpClientConfigurer implementation. I checked the jar file and all the following where included
That being said, I don’t know where the tracer gets its information from, but if it relies on thread locals to store then fetch context, then it definitely won’t work. Elasticsearch requests are processed and send from dedicated thread pools, not from application threads. That might explain why you’re not getting any trace?
I am not completely sure to be honest. I would have to research.
Did you put a breakpoint in MyBeanConfigurer as well? Also, did you start the application with mvnw clean quarkus:dev -Dsuspend? The code is executed right on startup, so if you connect your debugger one second after the startup, it won’t catch anything.
Not really. Passing the tracing context from the application threads to the thread pools that actually send the Elasticsearch requests would require changes to Hibernate Search; I don’t think there’s anything you can do as a user with the current version of Hibernate Search. But the next versions could support it
If you’re interested in such modifications, you can open a ticket and describe how you think this should be configured from the user’s point of view. Ideally, if you have any idea, you could also explain how to get the context the tracer needs from the application thread, and how to pass the context to the tracer… or even propose a solution
We’ll want this to be implemented in a technologically agnostic way, i.e. without a direct dependency from pre-existing Hibernate Search modules to Jaeger. That can be achieved by defining an SPI and one implementation per technology (Jaeger, …), or by relying on a “standard” API such as OpenTracing.