cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joshua McKenzie (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-10984) Cassandra should not depend on netty-all
Date Sun, 10 Jan 2016 22:48:40 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Joshua McKenzie updated CASSANDRA-10984:
----------------------------------------
    Assignee: Alex Petrov

> 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
>            Assignee: Alex Petrov
>            Priority: Minor
>         Attachments: 0001-Use-separate-netty-depencencies-instead-of-netty-all.patch,
0001-with-binaries.patch
>
>
> 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)

Mime
View raw message