[jira] [Commented] (CASSANDRA-10984) Cassandra should not depend on netty-all
[ https://issues.apache.org/jira/browse/CASSANDRA-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228988#comment-15228988 ] Alex Petrov commented on CASSANDRA-10984: - {{cassandra-driver-core}} is a bit different issue. I'd fire up the ticket here: https://datastax-oss.atlassian.net/projects/JAVA/issues Although, I have to say that java-driver is not using {{netty-all}}, they use individual deps, so looks like in this case Dataflow might use {{all}} :) (wild guess) > 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.(PoolArena.java:64) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PoolArena$HeapArena.(PoolArena.java:593) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:179) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:153) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:145) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:128) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > org.apache.cassandra.transport.CBUtil.(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)
[jira] [Commented] (CASSANDRA-10984) Cassandra should not depend on netty-all
[ https://issues.apache.org/jira/browse/CASSANDRA-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228978#comment-15228978 ] Alex Petrov commented on CASSANDRA-10984: - I mostly meant that if there's a class name collision, using {{netty-all}} would quoting OP "put you at grace of classloader", since {{netty-all}} shades all deps, and using individual deps allows user overriding (assuming APIs are kept intact within C* / dependant version). But I agree about the effort... > 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.(PoolArena.java:64) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PoolArena$HeapArena.(PoolArena.java:593) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:179) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:153) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:145) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:128) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > org.apache.cassandra.transport.CBUtil.(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)
[jira] [Commented] (CASSANDRA-10984) Cassandra should not depend on netty-all
[ https://issues.apache.org/jira/browse/CASSANDRA-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15214176#comment-15214176 ] Vassil Lunchev commented on CASSANDRA-10984: I am having a very similar problem with cassandra-driver-core 3.0.0 and Google Dataflow. Deploying to Dataflow sometimes works, sometimes gives the netty exception: "java.lang.NoSuchMethodError: io.netty.util.internal.PlatformDependent.newLongCounter()Lio/netty/util/internal/LongCounter; at io.netty.buffer.PoolArena.(PoolArena.java:64) at io.netty.buffer.PoolArena$HeapArena.(PoolArena.java:593) at io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:179) at io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:153) at io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:145) at io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:128) at com.datastax.driver.core.NettyOptions.afterBootstrapInitialized(NettyOptions.java:141) at com.datastax.driver.core.Connection$Factory.newBootstrap(Connection.java:825) at com.datastax.driver.core.Connection$Factory.access$100(Connection.java:677) at com.datastax.driver.core.Connection.initAsync(Connection.java:129) at com.datastax.driver.core.Connection$Factory.open(Connection.java:731) at com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:251) at com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:199) at com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77) at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1414) at com.datastax.driver.core.Cluster.init(Cluster.java:162) at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:333) at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:308) at com.datastax.driver.core.Cluster.connect(Cluster.java:250) Is there a known workaround for now? > 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.(PoolArena.java:64) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PoolArena$HeapArena.(PoolArena.java:593) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:179) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:153) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:145) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:128) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > org.apache.cassandra.transport.CBUtil.(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. -
[jira] [Commented] (CASSANDRA-10984) Cassandra should not depend on netty-all
[ https://issues.apache.org/jira/browse/CASSANDRA-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189461#comment-15189461 ] T Jake Luciani commented on CASSANDRA-10984: bq. FWIW, even splitting won't solve the issue since Cassandra does depend on `common`, even if it wouldn't depend directly it would still depend on `buffer` which depends on `common`. Does that mean this doesn't address your original concern? I'm not sure this is worth the effort tbh. What do you think [~norman]? > 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.(PoolArena.java:64) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PoolArena$HeapArena.(PoolArena.java:593) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:179) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:153) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:145) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:128) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > org.apache.cassandra.transport.CBUtil.(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)
[jira] [Commented] (CASSANDRA-10984) Cassandra should not depend on netty-all
[ https://issues.apache.org/jira/browse/CASSANDRA-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090788#comment-15090788 ] Aleksey Yeschenko commented on CASSANDRA-10984: --- Without a patch, it's unlikely that a contributor would get to this any time soon (got too many other higher priority issues atm). But a patch will be reviewed and tested. > 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.(PoolArena.java:64) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PoolArena$HeapArena.(PoolArena.java:593) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:179) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:153) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:145) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:128) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > org.apache.cassandra.transport.CBUtil.(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)
[jira] [Commented] (CASSANDRA-10984) Cassandra should not depend on netty-all
[ 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.(PoolArena.java:64) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PoolArena$HeapArena.(PoolArena.java:593) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:179) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:153) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:145) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:128) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > org.apache.cassandra.transport.CBUtil.(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)
[jira] [Commented] (CASSANDRA-10984) Cassandra should not depend on netty-all
[ https://issues.apache.org/jira/browse/CASSANDRA-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089492#comment-15089492 ] Aleksey Yeschenko commented on CASSANDRA-10984: --- Do you know which deps we *actually* need? > 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.(PoolArena.java:64) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PoolArena$HeapArena.(PoolArena.java:593) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:179) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:153) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:145) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:128) > ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final] > [JVM-1] at > org.apache.cassandra.transport.CBUtil.(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)