[ 
https://issues.apache.org/jira/browse/CASSANDRA-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090787#comment-15090787
 ] 

Oleksandr Petrov commented on CASSANDRA-10984:
----------------------------------------------

>From what I can see right now, it's `netty-buffer`, `codec`, `common`, 
>`handler`, `transport`, `transport-native-epoll` 

`netty-all` itself includes quite a few other things (such as DNS, example and 
so on). Do you think a patch for that would be useful?

> Cassandra should not depend on netty-all
> ----------------------------------------
>
>                 Key: CASSANDRA-10984
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10984
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: James Roper
>            Priority: Minor
>
> netty-all is a jar that bundles all the individual netty dependencies for 
> convenience together for people trying out netty to get started quickly.  
> Serious projects like Cassandra should never ever ever use it, since it's a 
> recipe for classpath disasters.
> To illustrate, I'm running Cassandra embedded in an app, and I get this error:
> {noformat}
> [JVM-1] java.lang.NoSuchMethodError: 
> io.netty.util.internal.PlatformDependent.newLongCounter()Lio/netty/util/internal/LongCounter;
> [JVM-1]       at io.netty.buffer.PoolArena.<init>(PoolArena.java:64) 
> ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1]       at 
> io.netty.buffer.PoolArena$HeapArena.<init>(PoolArena.java:593) 
> ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1]       at 
> io.netty.buffer.PooledByteBufAllocator.<init>(PooledByteBufAllocator.java:179)
>  ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1]       at 
> io.netty.buffer.PooledByteBufAllocator.<init>(PooledByteBufAllocator.java:153)
>  ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1]       at 
> io.netty.buffer.PooledByteBufAllocator.<init>(PooledByteBufAllocator.java:145)
>  ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1]       at 
> io.netty.buffer.PooledByteBufAllocator.<clinit>(PooledByteBufAllocator.java:128)
>  ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1]       at 
> org.apache.cassandra.transport.CBUtil.<clinit>(CBUtil.java:56) 
> ~[cassandra-all-3.0.0.jar:3.0.0]
> [JVM-1]       at org.apache.cassandra.transport.Server.start(Server.java:134) 
> ~[cassandra-all-3.0.0.jar:3.0.0]
> {noformat}
> {{PlatformDependent}} comes from netty-common, of which version 4.0.33 is on 
> the classpath, but it's also provided by netty-all, which has version 4.0.23 
> brought in by cassandra.  By a fluke of classpath ordering, the classloader 
> has loaded the netty buffer classes from netty-buffer 4.0.33, but the 
> PlatformDependent class from netty-all 4.0.23, and these two versions are not 
> binary compatible, hence the linkage error.
> Essentially to avoid these problems in serious projects, anyone that ever 
> brings in cassandra is going to have to exclude the netty dependency from it, 
> which is error prone, and when you get it wrong, due to the nature of 
> classpath ordering bugs, it might not be till you deploy to production that 
> you actually find out there's a problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to