[
https://issues.apache.org/jira/browse/CASSANDRA-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168418#comment-14168418
]
Bill Mitchell edited comment on CASSANDRA-8062 at 10/12/14 12:27 AM:
---------------------------------------------------------------------
Still using the same 2.1 sources I downloaded last weekend, I ran Cassandra in
debug mode while also running my JUnit test. On first glance, this appears to
be an issue on the server side.
Looking in the log above, I see on the PREPARE statement a trailing v=2 which
makes me think it is specifying protocol version 2. When I step back up the
debug stack, Buffer.limit was passed a newLimit of 2097192,
ByteBufferUtil.readBytes(:543) was passed a length of 2097152,
CollectionSerializer.readValue(:122) was passed a version of 3, so it retrieved
a four byte int value. If I back up from the now current position of 40, I see
in input, input[36]=0, input[37]=32, input[38]=0, input[39]=0. This has the
appearance of parsing a 4 byte size when it was passed a 2 byte size. Stepping
up two more levels to CollectionSerializer.deserialize(ByteBuffer)(:48), one
sees where it forces the version number to 3, apparently thinking that only
internal ByteBuffers are passed through this path, and these would all be v3.
Of course, it may still be a driver bug, if the driver must use protocol v3 to
pass such a statement. Looking at the driver interface, though,
Cluster.Builder accepts only protocol versions 1 or 2.
was (Author: wtmitchell3):
Still using the same 2.1 sources I downloaded last weekend, I ran Cassandra in
debug mode while also running my JUnit test. On first glance, this appears to
be an issue on the server side.
Looking in the log above, I see on the PREPARE statement a trailing v=2 which
makes me think it is specifying protocol version 2. When I step back up the
debug stack, Buffer.limit was passed a newLimit of 2097192,
ByteBufferUtil.readBytes(:543) was passed a length of 2097152,
CollectionSerializer.readValue(:122) was passed a version of 3, so it retrieved
a four byte int value. If I back up from the now current position of 40, I see
in input, input[36]=0, input[37]=32, input[38]=0, input[39]=0. This has the
appearance of parsing a 4 byte size when it was passed a 2 byte size. Stepping
up two more levels to CollectionSerializer.deserialize(ByteBuffer)(:48), one
sees where it forces the version number to 3, apparently thinking that only
internal ByteBuffers are passed through this path, and these would all be v3.
Of course, it may still be a driver bug, if the driver must use protocol v3 to
pass such a statement. Looking at the driver interface, though, the
ClusterBuilder accepts only protocol versions 1 or 2.
> IllegalArgumentException passing blob as tuple value element in list
> --------------------------------------------------------------------
>
> Key: CASSANDRA-8062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8062
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows 7, DataStax 2.1.0 Cassandra server, Java
> cassandra-driver-2.1.1
> Reporter: Bill Mitchell
> Assignee: Tyler Hobbs
>
> I am using the same table schema as described in earlier reports, e.g.,
> CASSANDRA-7105:
> {code}
> CREATE TABLE sr (siteid uuid, listid bigint, partition int, createdate
> timestamp, emailcrypt blob, emailaddr text, properties text, removedate
> timestamp. removeimportid bigint,
> PRIMARY KEY ((siteid, listid, partition), createdate, emailcrypt)
> ) WITH CLUSTERING ORDER BY (createdate DESC, emailcrypt DESC);
> {code}
> I am trying to take advantage of the new Tuple support to issue a query to
> request multiple rows in a single wide row by (createdate,emailcrypt) pair.
> I declare a new TupleType that covers the clustering columns and then issue
> an IN predicate against a list of these values:
> {code}
> private static final TupleType dateEmailTupleType =
> TupleType.of(DataType.timestamp(), DataType.blob());
> ...
> List<TupleValue> partitionKeys = new ArrayList<>(recipKeys.size());
> ...
> BoundStatement boundStatement = new BoundStatement(preparedStatement);
> boundStatement = boundStatement.bind(siteID, partition, listID);
> boundStatement.setList(3, partitionKeys);
> {code}
> When I issue a SELECT against this table, the server fails apparently trying
> to break apart the list values:
> {code}
> DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:15,312 Message.java:420 -
> Received: PREPARE SELECT emailCrypt, emailAddr, removeDate, removeImportID,
> properties FROM sr WHERE siteID = ? AND partition = ? AND listID = ? AND (
> createDate, emailCrypt ) IN ? ;, v=2
> DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:15,323 Tracing.java:157 -
> request complete
> DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:15,323 Message.java:433 -
> Responding: RESULT PREPARED a18ff9151e8bd3b13b48a0ba56ecb784
> [siteid(testdb_1412536748414, sr),
> org.apache.cassandra.db.marshal.UUIDType][partition(testdb_1412536748414,
> sr), org.apache.cassandra.db.marshal.Int32Type][listid(testdb_1412536748414,
> sr),
> org.apache.cassandra.db.marshal.LongType][in(createdate,emailcrypt)(testdb_1412536748414,
> sr),
> org.apache.cassandra.db.marshal.ListType(org.apache.cassandra.db.marshal.TupleType(org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimestampType),org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.BytesType)))]
> (resultMetadata=[emailcrypt(testdb_1412536748414, sr),
> org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.BytesType)][emailaddr(testdb_1412536748414,
> sr),
> org.apache.cassandra.db.marshal.UTF8Type][removedate(testdb_1412536748414,
> sr),
> org.apache.cassandra.db.marshal.TimestampType][removeimportid(testdb_1412536748414,
> sr),
> org.apache.cassandra.db.marshal.LongType][properties(testdb_1412536748414,
> sr), org.apache.cassandra.db.marshal.UTF8Type]), v=2
> DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:15,363 Message.java:420 -
> Received: EXECUTE a18ff9151e8bd3b13b48a0ba56ecb784 with 4 values at
> consistency QUORUM, v=2
> DEBUG [SharedPool-Worker-2] 2014-10-05 14:20:15,380 Message.java:420 -
> Received: EXECUTE a18ff9151e8bd3b13b48a0ba56ecb784 with 4 values at
> consistency QUORUM, v=2
> DEBUG [SharedPool-Worker-5] 2014-10-05 14:20:15,402 Message.java:420 -
> Received: EXECUTE a18ff9151e8bd3b13b48a0ba56ecb784 with 4 values at
> consistency QUORUM, v=2
> ERROR [SharedPool-Worker-5] 2014-10-05 14:20:16,125 ErrorMessage.java:218 -
> Unexpected exception during request
> java.lang.IllegalArgumentException: null
> at java.nio.Buffer.limit(Unknown Source) ~[na:1.7.0_25]
> at
> org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:539)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.serializers.CollectionSerializer.readValue(CollectionSerializer.java:122)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.serializers.ListSerializer.deserializeForNativeProtocol(ListSerializer.java:87)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.serializers.ListSerializer.deserializeForNativeProtocol(ListSerializer.java:27)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.serializers.CollectionSerializer.deserialize(CollectionSerializer.java:48)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:66)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.Tuples$InValue.fromSerialized(Tuples.java:249)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at org.apache.cassandra.cql3.Tuples$InMarker.bind(Tuples.java:394)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.MultiColumnRestriction$InWithMarker.splitValues(MultiColumnRestriction.java:103)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.buildMultiColumnInBound(SelectStatement.java:951)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.buildBound(SelectStatement.java:806)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getRequestedBound(SelectStatement.java:1012)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:448)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:336)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:237)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:200)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:60)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:187)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:413)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:133)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:422)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:318)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:103)
> ~[netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> ~[netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:31)
> ~[netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:323)
> ~[netty-all-4.0.20.Final.jar:4.0.20.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> ~[na:1.7.0_25]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:163)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at java.lang.Thread.run(Unknown Source) ~[na:1.7.0_25]
> ERROR [SharedPool-Worker-1] 2014-10-05 14:20:16,125 ErrorMessage.java:218 -
> Unexpected exception during request
> java.lang.IllegalArgumentException: null
> ...
> ERROR [SharedPool-Worker-2] 2014-10-05 14:20:16,125 ErrorMessage.java:218 -
> Unexpected exception during request
> java.lang.IllegalArgumentException: null
> ...
> DEBUG [SharedPool-Worker-5] 2014-10-05 14:20:16,126 Tracing.java:157 -
> request complete
> DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:16,126 Tracing.java:157 -
> request complete
> DEBUG [SharedPool-Worker-2] 2014-10-05 14:20:16,126 Tracing.java:157 -
> request complete
> DEBUG [SharedPool-Worker-5] 2014-10-05 14:20:16,126 Message.java:433 -
> Responding: ERROR SERVER_ERROR: java.lang.IllegalArgumentException, v=2
> DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:16,126 Message.java:433 -
> Responding: ERROR SERVER_ERROR: java.lang.IllegalArgumentException, v=2
> DEBUG [SharedPool-Worker-2] 2014-10-05 14:20:16,127 Message.java:433 -
> Responding: ERROR SERVER_ERROR: java.lang.IllegalArgumentException, v=2
> {code}
> (There are three exceptions as the client code issues three concurrent
> asynchronous requests.)
> There is a fair chance this is a Java driver bug serializing the data into
> the message, but I'm reporting this against the server as that is where the
> exception occurs. If I had a simple DAO layer above the driver, I would
> attach a simple testcase, but I don't.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
