[jira] [Comment Edited] (CASSANDRA-10984) Cassandra should not depend on netty-all

2016-03-28 Thread Vassil Lunchev (JIRA)

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

Vassil Lunchev edited comment on CASSANDRA-10984 at 3/28/16 1:17 PM:
-

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:

{code:java}
"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)
{code}

Is there a known workaround for now?


was (Author: vas...@leanplum.com):
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] 

[jira] [Comment Edited] (CASSANDRA-10984) Cassandra should not depend on netty-all

2016-01-10 Thread Alex Petrov (JIRA)

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

Alex Petrov edited comment on CASSANDRA-10984 at 1/10/16 7:16 PM:
--

I've uploaded two patches: one contains changes only to build.xml (in case 
you'd like to make sure that binaries are correct yourself) and the same exact 
patch only with binaries I've downloaded from netty maven repository.

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`.


was (Author: ifesdjeen):
I've uploaded two patches: one contains changes only to build.xml (in case 
you'd like to make sure that binaries are correct yourself) and the same exact 
patch only with binaries I've downloaded from netty maven repository.

> 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
> 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)