Nikola Grcevski

Thanks for reporting this @mehmetyazicioglu. This is unusual and I'm wondering if it's somehow related to a new feature we introduced to fetch the HTTP routes of Java applications. Do...

Interesting... we don't use it unless you have enabled: ``` ebpf: use_otel_sdk_for_java: true ``` or via the environment variable: OTEL_EBPF_USE_OTEL_SDK_FOR_JAVA=true If those are set, we'll try to inject the actual...

If you can share your config we can try to reproduce this ourselves.

Thanks for this @mehmetyazicioglu. I think the only thing that might potentially affect the database connections in this way is our context propagation, unless I'm missing something. Do you mind...

It might be possible it's a duplicate of https://github.com/grafana/beyla/issues/2293. This specific issue I mentioned here is concerning with context_propagation: "all" with IPv6. It's possible that the client is using IPv6...

Thanks for trying it out! In general the context propagation with "all" which includes the IP options field covers more cases, but I think it's causing some issue in this...

This isn't confirmed that it's the same issue as the IPv6, we need to keep it open for now.

> well, let's start with 24-ea 😄 [#13376](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/13376) Thanks for the quick response @trask! I tested locally with the 24-rc1 and it works well, at least in my limited tests...

This actually didn't quite work. We can't read the SSL BIO like that for a few reasons: - Doesn't work with boringssl, they use a different struct. - Doesn't work...

We'd welcome that contribution @prateek041, let us know if you need anything from our side.