We're updating the issue view to help you get more done. 

Consider backing off to nio if epoll is present but fails to load

Description

Currently the java driver will fall back on NIO if it detects that io.netty.channel.epoll.Epoll is not on the classpath.

However, if the user has Epoll in their classpath but it fails to load because of incompatibilities between netty jars in their classpath the driver fails to intialize a Cluster.

An example of this happening is if the user has an older version of netty-all in their classpath (possibly pulled in by dependent libraries like hadoop), but a newer version of netty-transport in their classpath that was pulled in by the driver. Since netty-all is an uber jar of all the netty libraries it includes netty-transport-native-epoll. In such a situation, the user will see an exception like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Exception in thread "main" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at com.google.common.base.Throwables.propagate(Throwables.java:160) at com.datastax.driver.core.NettyUtil.newEventLoopGroupInstance(NettyUtil.java:127) at com.datastax.driver.core.NettyOptions.eventLoopGroup(NettyOptions.java:90) at com.datastax.driver.core.Connection$Factory.<init>(Connection.java:767) at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1437) at com.datastax.driver.core.Cluster.init(Cluster.java:150) at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:321) at com.datastax.driver.core.Cluster.connect(Cluster.java:271) at com.datastax.driver.core.DelegatingCluster.connect(DelegatingCluster.java:67) at com.datastax.driver.dse.DseCluster.connect(DseCluster.java:387) ... at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at com.datastax.driver.core.NettyUtil.newEventLoopGroupInstance(NettyUtil.java:125) ... 16 more Caused by: java.lang.NoSuchMethodError: io.netty.util.internal.PlatformDependent.newAtomicIntegerFieldUpdater(Ljava/lang/Class;Ljava/lang/String;)Ljava/util/concurrent/atomic/AtomicIntegerFieldUpdater; at io.netty.channel.epoll.EpollEventLoop.<clinit>(EpollEventLoop.java:43) at io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:71) at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64) at io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49) at io.netty.channel.epoll.EpollEventLoopGroup.<init>(EpollEventLoopGroup.java:56) at io.netty.channel.epoll.EpollEventLoopGroup.<init>(EpollEventLoopGroup.java:48) ... 21 more

A couple of users reported this after upgrading to 3.3.0 (which uses Netty 4.0.47.Final instead of Netty 4.0.44.Final like 3.2.0).

Since in this case the user doesn't have epoll in their classpath because they want to explicitly use it, it's just because a dependent library happened to pull it in as a transitive dependency we should fallback gracefully to NIO and inform the user of this.

Environment

None

Pull Requests

None

Status

Assignee

Unassigned

Reporter

Andy Tolbert

Labels

None

PM Priority

None

Reproduced in

None

External issue ID

None

External issue ID

None

External issue ID

None

External issue ID

None

External issue ID

None

External issue ID

None

Doc Impact

None

Reviewer

None

Size

None

Priority

Major