testcontainers / testcontainers/testcontainers-java
[Bug]: Not able to use Elastic Search Transport client because of duplicate java native library "libnet.dylib" load
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 8.7k
- Forks
- 1.9k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 9
Description
Module
Elasticsearch
Testcontainers version
1.17.6
Using the latest Testcontainers version?
Yes
Host OS
Mac Os
Host Arch
aarch_64
Docker version
Docker version 20.10.23, build 7155243
What happened?
Test container is loading the java native library "libnet.dylib" on startup. If the application is using an Elastic search transport client which also tries to load the name native library and fails.
Relevant log output
[elasticsearch[_client_][transport_worker][T#1]] - [ChannelInitializer] - Failed to initialize a channel. Closing: [id: 0x314081aa] java.lang.UnsatisfiedLinkError: Native Library /Library/Java/JavaVirtualMachines/jdk1.8.0_361.jdk/Contents/Home/jre/lib/libnet.dylib already loaded in another classloader
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1903) ~[?:1.8.0_361]
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1841) ~[?:1.8.0_361]
at java.lang.Runtime.loadLibrary0(Runtime.java:843) ~[?:1.8.0_361]
at java.lang.System.loadLibrary(System.java:1134) ~[?:1.8.0_361]
at jdk.net.MacOSXSocketOptions.<clinit>(MacOSXSocketOptions.java:78) ~[?:1.8.0_361]
at java.lang.Class.forName0(Native Method) ~[?:1.8.0_361]
at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_361]
at jdk.net.ExtendedSocketOptions$PlatformSocketOptions.newInstance(ExtendedSocketOptions.java:286) ~[?:1.8.0_361]
at jdk.net.ExtendedSocketOptions$PlatformSocketOptions.create(ExtendedSocketOptions.java:305) ~[?:1.8.0_361]
at jdk.net.ExtendedSocketOptions$PlatformSocketOptions.<clinit>(ExtendedSocketOptions.java:311) ~[?:1.8.0_361]
at jdk.net.ExtendedSocketOptions.<clinit>(ExtendedSocketOptions.java:136) ~[?:1.8.0_361]
at java.lang.Class.forName0(Native Method) ~[?:1.8.0_361]
at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_361]
at org.elasticsearch.core.internal.net.NetUtils.getExtendedSocketOptionOrNull(NetUtils.java:47) ~[elasticsearch-core-7.17.0.jar:7.17.0]
at org.elasticsearch.core.internal.net.NetUtils.getTcpKeepIdleSocketOptionOrNull(NetUtils.java:27) ~[elasticsearch-core-7.17.0.jar:7.17.0]
at org.elasticsearch.core.internal.net.NetUtils.tryEnsureReasonableKeepAliveConfig(NetUtils.java:70) ~[elasticsearch-core-7.17.0.jar:7.17.0]
at org.elasticsearch.transport.netty4.Netty4Transport$ClientChannelInitializer.initChannel(Netty4Transport.java:329) [transport-netty4-client-7.17.0.jar:7.17.0]
at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115) [netty-transport-4.1.29.Final.jar:4.1.29.Final]
at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107) [netty-transport-4.1.29.Final.jar:4.1.29.Final]
Additional Information
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the Elasticsearch module on macOS aarch64 with Testcontainers 1.17.6, Docker 20.10.23, and the Elastic Search Transport client, starting from the reported UnsatisfiedLinkError. Inspect the Elasticsearch startup and transport-client interaction around libnet.dylib loading; done means the transport client connects without the duplicate native-library failure.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, elasticsearch, java
- Domain
- search, testing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100