[jira] [Commented] (CASSANDRA-7048) Cannot get comparator 2 in CompositeType
[
https://issues.apache.org/jira/browse/CASSANDRA-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14484956#comment-14484956
]
Ben Hood commented on CASSANDRA-7048:
-
Sorry for the delay in responding to this.
I have not been able to reproduce this issue for a while now, and given that
I've only been able to reproduce it on 2.0.6, I think we can close probably
close it.
Cannot get comparator 2 in CompositeType
Key: CASSANDRA-7048
URL: https://issues.apache.org/jira/browse/CASSANDRA-7048
Project: Cassandra
Issue Type: Bug
Environment: Archlinux, AWS m1.large
Reporter: Ben Hood
Attachments: cassandra.log.zip
I've left a Cassandra instance in limbo for the last days, meaning that it
has been happily serving read requests, but I've cut off the data ingress,
but I was doing some read-only development.
After not writing anything to Cassandra for a few days, I got the following
error for the first write to Cassandra:
{code}
Caused by: java.lang.RuntimeException: Cannot get comparator 2 in
org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.TimestampType,org.apache.cassandra.db.marshal.UTF8Type).
This might due to a mismatch between the schema and the data read
at
org.apache.cassandra.db.marshal.CompositeType.getComparator(CompositeType.java:133)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:137)
at
org.apache.cassandra.db.filter.ColumnCounter$GroupByPrefix.count(ColumnCounter.java:115)
at
org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:192)
at
org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:122)
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:80)
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:72)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:297)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1551)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1380)
at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:327)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:65)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1341)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1896)
... 3 more
Caused by: java.lang.IndexOutOfBoundsException: index (2) must be less than
size (2)
at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:306)
at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:285)
at
com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:65)
at
org.apache.cassandra.db.marshal.CompositeType.getComparator(CompositeType.java:124)
... 17 more{code}
I'm not sure whether this is the root cause, so I'm attaching the server log
file.
I'm going to try to investigate a bit further, to see what changes, if any
the application driver introduced.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251922#comment-14251922
]
Ben Hood commented on CASSANDRA-7304:
-
Many thanks for updating the summary. Can I assume that when this patch lands,
then there will be an observable different in the wire protocol - i.e. if a
driver sends a values of -2, then this will avoid tombstones? If so, then a
driver that supports this differentiation can only be used as of this updated
of the server.
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-04.patch, 7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
*EDIT 18/12/14 - [~odpeer] Implementation Notes:*
The motivation hasn't changed.
Protocol version 4 specifies that bind variables do not require having a
value when executing a statement. Bind variables without a value are called
'unset'. The 'unset' bind variable is serialized as the int value '-2'
without following bytes.
\\
\\
* An unset bind variable in an EXECUTE or BATCH request
** On a {{value}} does not modify the value and does not create a tombstone
** On the {{ttl}} clause is treated as 'unlimited'
** On the {{timestamp}} clause is treated as 'now'
** On a map key or a list index throws {{InvalidRequestException}}
** On a {{counter}} increment or decrement operation does not change the
counter value, e.g. {{UPDATE my_tab SET c = c - ? WHERE k = 1}} does change
the value of counter {{c}}
** On a tuple field or UDT field throws {{InvalidRequestException}}
* An unset bind variable in a QUERY request
** On a partition column, clustering column or index column in the {{WHERE}}
clause throws {{InvalidRequestException}}
** On the {{limit}} clause is treated as 'unlimited'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252148#comment-14252148
]
Ben Hood commented on CASSANDRA-7304:
-
The point about needing the updated server version is important - thanks very
much for clarifying this.
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-04.patch, 7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
*EDIT 18/12/14 - [~odpeer] Implementation Notes:*
The motivation hasn't changed.
Protocol version 4 specifies that bind variables do not require having a
value when executing a statement. Bind variables without a value are called
'unset'. The 'unset' bind variable is serialized as the int value '-2'
without following bytes.
\\
\\
* An unset bind variable in an EXECUTE or BATCH request
** On a {{value}} does not modify the value and does not create a tombstone
** On the {{ttl}} clause is treated as 'unlimited'
** On the {{timestamp}} clause is treated as 'now'
** On a map key or a list index throws {{InvalidRequestException}}
** On a {{counter}} increment or decrement operation does not change the
counter value, e.g. {{UPDATE my_tab SET c = c - ? WHERE k = 1}} does change
the value of counter {{c}}
** On a tuple field or UDT field throws {{InvalidRequestException}}
* An unset bind variable in a QUERY request
** On a partition column, clustering column or index column in the {{WHERE}}
clause throws {{InvalidRequestException}}
** On the {{limit}} clause is treated as 'unlimited'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14249679#comment-14249679 ] Ben Hood commented on CASSANDRA-7304: - We've had [an issue raised with us at gocql|https://github.com/gocql/gocql/issues/296] that would like to take advantage of these changes, but I'm not 100% what the final scope of this patch will be. One first glance it looked like these were just driver side changes, and hence we were considering to what extent we could replicate this in our driver. There was mention that the wire protocol would be clarified to include the UNSET (-2) flag. But reading the latest patch, it looks like there might be some server side changes as well. To be fair, it looks like the understanding of what needs to happen has evolved since the issue was first raised. So I was wondering whether the intention of this can get restated of the benefit of external readers. Would it be possible to update the original summary to reflect the current motivation and scope of the change? Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Sub-task Reporter: Drew Kutcharian Assignee: Oded Peer Labels: cql, protocolv4 Fix For: 3.0 Attachments: 7304-03.patch, 7304-04.patch, 7304-2.patch, 7304.patch Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7576) DateType columns not properly converted to TimestampType when in ReversedType columns.
[
https://issues.apache.org/jira/browse/CASSANDRA-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14068328#comment-14068328
]
Ben Hood commented on CASSANDRA-7576:
-
FWIW, you could verify this patch by removing this workaround
(https://github.com/gocql/gocql/pull/154) that we put into place to deal with
this issue in gocql.
DateType columns not properly converted to TimestampType when in ReversedType
columns.
--
Key: CASSANDRA-7576
URL: https://issues.apache.org/jira/browse/CASSANDRA-7576
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Karl Rieb
Attachments: DataType_CASSANDRA_7576.patch
Original Estimate: 0.25h
Remaining Estimate: 0.25h
The {{org.apache.cassandra.transport.DataType.fromType(AbstractType)}} method
has a bug that prevents sending the correct Protocol ID for reversed
{{DateType}} columns. This results in clients receiving Protocol ID {{0}},
which maps to a {{CUSTOM}} type, for timestamp columns that are clustered in
reverse order.
Some clients can handle this properly since they recognize the
{{org.apache.cassandra.db.marshal.DateType}} marshaling type, however the
native Datastax java-driver does not. It will produce errors like the one
below when trying to prepare queries against such tables:
{noformat}
com.datastax.driver.core.exceptions.InvalidTypeException: Invalid type
for value 2 of CQL type 'org.apache.cassandra.db.marshal.DateType', expecting
class java.nio.ByteBuffer but class java.util.Date provided
at com.datastax.driver.core.BoundStatement.bind(BoundStatement.java:190)
at
com.datastax.driver.core.DefaultPreparedStatement.bind(DefaultPreparedStatement.java:103)
{noformat}
On the Cassandra side, there is a check for {{DateType}} columns that is
supposed to convert these columns to TimestampType. However, the check is
skipped when the column is also reversed. Specifically:
{code:title=DataType.java|borderStyle=solid}
public static PairDataType, Object fromType(AbstractType type)
{
// For CQL3 clients, ReversedType is an implementation detail and they
// shouldn't have to care about it.
if (type instanceof ReversedType)
type = ((ReversedType)type).baseType;
// For compatibility sake, we still return DateType as the timestamp type
in resultSet metadata (#5723)
else if (type instanceof DateType)
type = TimestampType.instance;
// ...
{code}
The *else if* should be changed to just an *if*, like so:
{code:title=DataType.java|borderStyle=solid}
public static PairDataType, Object fromType(AbstractType type)
{
// For CQL3 clients, ReversedType is an implementation detail and they
// shouldn't have to care about it.
if (type instanceof ReversedType)
type = ((ReversedType)type).baseType;
// For compatibility sake, we still return DateType as the timestamp type
in resultSet metadata (#5723)
if (type instanceof DateType)
type = TimestampType.instance;
// ...
{code}
This bug is preventing us from upgrading our 1.2.11 cluster to 2.0.9 because
our clients keep throwing exceptions trying to read or write data to tables
with reversed timestamp columns. This issue can be reproduced by creating a
CQL table in Cassandra 1.2.11 that clusters on a timestamp in reverse, then
upgrading the node to 2.0.9. When querying the metadata for the table, the
node will return Protocol ID 0 (CUSTOM) instead of Protocol ID 11 (TIMESTAMP).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7454) NPE When Prepared Statement ID is not Found
[
https://issues.apache.org/jira/browse/CASSANDRA-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14068366#comment-14068366
]
Ben Hood commented on CASSANDRA-7454:
-
I can confirm that this fix (as applied to 2.1-rc4) has resolved part of the an
issue reported in https://issues.apache.org/jira/browse/CASSANDRA-7566.
When I run the the TestReprepareStatement test case from the gocql integration
suite against the 2.1-rc3 tarball, it fails:
{code}
bool:gocql 0x6e6562$ go test . -v -test.run=TestReprepareStatement
=== RUN TestReprepareStatement
--- FAIL: TestReprepareStatement (0.31 seconds)
cassandra_test.go:588: Failed to execute query for reprepare statement:
java.lang.NullPointerException
FAIL
exit status 1
{code}
But when I run it against the 2.1-rc4 tarball, it passes:
{code}
bool:gocql 0x6e6562$ go test . -v -test.run=TestReprepareStatement
=== RUN TestReprepareStatement
--- PASS: TestReprepareStatement (0.25 seconds)
PASS
ok github.com/relops/gocql 0.267s
{code}
NPE When Prepared Statement ID is not Found
---
Key: CASSANDRA-7454
URL: https://issues.apache.org/jira/browse/CASSANDRA-7454
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Fix For: 2.1.0
Attachments: 7475.txt
CASSANDRA-6855 introduced a NullPointerException when an unknown prepared
statement ID is used.
You'll see a stack trace like this:
{noformat}
ERROR [SharedPool-Worker-4] 2014-06-26 15:02:04,911 ErrorMessage.java:218 -
Unexpected exception during request
java.lang.NullPointerException: null
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:105)
~[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:412)
[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:309)
[main/:na]
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(Executors.java:471)
[na:1.7.0_40]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:162)
[main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103)
[main/:na]
at java.lang.Thread.run(Thread.java:724) [na:1.7.0_40]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
Ben Hood created CASSANDRA-7566: --- Summary: DROP/CREATE TABLE cycle causes unrecognized column family Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065075#comment-14065075 ] Ben Hood commented on CASSANDRA-7566: - CASSANDRA-5202 appears to have been fixed in 2.1 beta1, but the version I'm using is 2.1-rc3. Is 2.1 beta 1 a newer release than 2.1-rc3? DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065090#comment-14065090 ] Ben Hood commented on CASSANDRA-7566: - The CQL that is submitted in this test is: DROP TABLE IF EXISTS wiki_page; followed by CREATE TABLE wiki_page (...); So I'm not seeing why this should result in a server error. Also, this is not just an entry in the server log file, it causes a test to fail that passes on our Travis run for the 2.0.6 and 2.0.7 releases. DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065343#comment-14065343 ] Ben Hood commented on CASSANDRA-7566: - [~yukim] Yes, gocql does prepare all statements by default. I could see if I can disable this behavior in the gocql driver and see if that has an effect. DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[
https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065376#comment-14065376
]
Ben Hood commented on CASSANDRA-7566:
-
OK, so the plot thickens.
By disabling statement preparation in the driver, I was able to workaround this
issue (see this patch for a workaround for this particular test case).
That said, I have noticed that another test fails for a different reason. Now
the test called TestReprepareStatement
(https://github.com/gocql/gocql/blob/master/cassandra_test.go#L582) which tests
the handling of statement re-preparation now fails with this server error:
{noformat}
INFO 18:56:03 Initializing gocql_test.test_reprepare_statement
ERROR 18:56:03 Unexpected exception during request
java.lang.NullPointerException: null
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:105)
~[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:421)
[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:318)
[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
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(Executors.java:511)
[na:1.8.0_05]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:162)
[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103)
[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_05]
{noformat}
This looks like two different bugs and potentially should be handled by two
separate bug reports?
DROP/CREATE TABLE cycle causes unrecognized column family
-
Key: CASSANDRA-7566
URL: https://issues.apache.org/jira/browse/CASSANDRA-7566
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: OSX 10.9.4 / JDK 1.8.0_05
Reporter: Ben Hood
Assignee: Yuki Morishita
An integration test suite that drops and creates the same column family 3
times causes the following error in the server log:
INFO 15:40:34 Initializing gocql_test.wiki_page
ERROR 15:40:34 Attempted to write commit log entry for unrecognized column
family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2
ERROR 15:40:34 Attempting to mutate non-existant column family
b0e167e0-0dc8-11e4-9cbb-29a4872887f2
ERROR 15:40:34 Attempted to write commit log entry for unrecognized column
family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2
ERROR 15:40:34 Attempting to mutate non-existant column family
b0e167e0-0dc8-11e4-9cbb-29a4872887f2
The test that reproduces this issue is here:
https://github.com/gocql/gocql/blob/master/wiki_test.go
Interestingly this issue only occurs after the common table is
dropped/created for the 3rd time. If only one of the tests is run on its own,
this issue does not arise.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065383#comment-14065383 ] Ben Hood commented on CASSANDRA-7566: - For anybody coming across this issue via Google, the original pull request to gocql that provokes this error is here: https://github.com/gocql/gocql/pull/198 DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7048) Cannot get comparator 2 in CompositeType
Ben Hood created CASSANDRA-7048: --- Summary: Cannot get comparator 2 in CompositeType Key: CASSANDRA-7048 URL: https://issues.apache.org/jira/browse/CASSANDRA-7048 Project: Cassandra Issue Type: Bug Environment: Archlinux, AWS m1.large Reporter: Ben Hood Attachments: cassandra.log.zip I've left a Cassandra instance in limbo for the last days, meaning that it has been happily serving read requests, but I've cut off the data ingress, but I was doing some read-only development. After not writing anything to Cassandra for a few days, I got the following error for the first write to Cassandra: Caused by: java.lang.RuntimeException: Cannot get comparator 2 in org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.TimestampType,org.apache.cassandra.db.marshal.UTF8Type). This might due to a mismatch between the schema and the data read at org.apache.cassandra.db.marshal.CompositeType.getComparator(CompositeType.java:133) at org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:137) at org.apache.cassandra.db.filter.ColumnCounter$GroupByPrefix.count(ColumnCounter.java:115) at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:192) at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:122) at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:80) at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:72) at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:297) at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1551) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1380) at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:327) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:65) at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1341) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1896) ... 3 more Caused by: java.lang.IndexOutOfBoundsException: index (2) must be less than size (2) at com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:306) at com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:285) at com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:65) at org.apache.cassandra.db.marshal.CompositeType.getComparator(CompositeType.java:124) ... 17 more I'm not sure whether this is the root cause, so I'm attaching the server log file. I'm going to try to investigate a bit further, to see what changes, if any the application driver introduced. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6796) StorageProxy may submit hint to itself (with an assert) for CL.Any
[
https://issues.apache.org/jira/browse/CASSANDRA-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963998#comment-13963998
]
Ben Hood commented on CASSANDRA-6796:
-
I'm getting the following error with a 2.0.6 node - is this potentially
related?
{noformat}
ERROR [Native-Transport-Requests:16633] 2014-04-09 10:11:45,811
ErrorMessage.java (line 222) Unexpected exception during request
java.lang.AssertionError: localhost/127.0.0.1
at
org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:860)
at
org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:480)
at
org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:524)
at
org.apache.cassandra.cql3.statements.BatchStatement.executeWithoutConditions(BatchStatement.java:210)
at
org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:203)
at
org.apache.cassandra.cql3.statements.BatchStatement.executeWithPerStatementVariables(BatchStatement.java:192)
at
org.apache.cassandra.cql3.QueryProcessor.processBatch(QueryProcessor.java:373)
at
org.apache.cassandra.transport.messages.BatchMessage.execute(BatchMessage.java:206)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
StorageProxy may submit hint to itself (with an assert) for CL.Any
--
Key: CASSANDRA-6796
URL: https://issues.apache.org/jira/browse/CASSANDRA-6796
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Viktor Kuzmin
Priority: Minor
StorageProxy.mutate may produce WriteTimoutException and with
ConsistencyLevel.ANY it tries to submitHint. But submitHint function have
assertation - we may not send hints to ourself. That may lead to exception
(in case we're among natural endpoints) and hint will be not submitted to
other endpoints.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-6796) StorageProxy may submit hint to itself (with an assert) for CL.Any
[ https://issues.apache.org/jira/browse/CASSANDRA-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13964110#comment-13964110 ] Ben Hood edited comment on CASSANDRA-6796 at 4/9/14 12:52 PM: -- Are you saying that the fix is in the (as yet) unreleased 2.0.7? If so, what is the ticket id of the fix? was (Author: 0x6e6562): Are you saying that the fix is in the (as yet) unrelease 2.0.7? If so, what is the ticket id of the fix? StorageProxy may submit hint to itself (with an assert) for CL.Any -- Key: CASSANDRA-6796 URL: https://issues.apache.org/jira/browse/CASSANDRA-6796 Project: Cassandra Issue Type: Bug Components: Core Reporter: Viktor Kuzmin Priority: Minor Fix For: 2.0.7 StorageProxy.mutate may produce WriteTimoutException and with ConsistencyLevel.ANY it tries to submitHint. But submitHint function have assertation - we may not send hints to ourself. That may lead to exception (in case we're among natural endpoints) and hint will be not submitted to other endpoints. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6796) StorageProxy may submit hint to itself (with an assert) for CL.Any
[ https://issues.apache.org/jira/browse/CASSANDRA-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13964110#comment-13964110 ] Ben Hood commented on CASSANDRA-6796: - Are you saying that the fix is in the (as yet) unrelease 2.0.7? If so, what is the ticket id of the fix? StorageProxy may submit hint to itself (with an assert) for CL.Any -- Key: CASSANDRA-6796 URL: https://issues.apache.org/jira/browse/CASSANDRA-6796 Project: Cassandra Issue Type: Bug Components: Core Reporter: Viktor Kuzmin Priority: Minor Fix For: 2.0.7 StorageProxy.mutate may produce WriteTimoutException and with ConsistencyLevel.ANY it tries to submitHint. But submitHint function have assertation - we may not send hints to ourself. That may lead to exception (in case we're among natural endpoints) and hint will be not submitted to other endpoints. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6796) StorageProxy may submit hint to itself (with an assert) for CL.Any
[ https://issues.apache.org/jira/browse/CASSANDRA-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13964122#comment-13964122 ] Ben Hood commented on CASSANDRA-6796: - Oh, OK - it was hard to tell whether he meant that this issue is fixed by some other fixes, seeing as there are a couple of other reference tickets earlier on in the discussion thread, hence my question. By looking at the assertion at L860 in StorageProxy.java it looks like this issue is masking an underlying timeout - if this assumption is wrong, please let me know. So based on this assumption, what I've done in the meantime is to increase write_request_timeout_in_ms in cassandra.yaml from 2000 to 1. My particular workload is very batchy, so I figured, what could possibly go wrong. For now, this change in the setting seems to avoid the this issue. But this might be happenstance - is write_request_timeout_in_ms something I probably shouldn't be playing with? StorageProxy may submit hint to itself (with an assert) for CL.Any -- Key: CASSANDRA-6796 URL: https://issues.apache.org/jira/browse/CASSANDRA-6796 Project: Cassandra Issue Type: Bug Components: Core Reporter: Viktor Kuzmin Priority: Minor Fix For: 2.0.7 StorageProxy.mutate may produce WriteTimoutException and with ConsistencyLevel.ANY it tries to submitHint. But submitHint function have assertation - we may not send hints to ourself. That may lead to exception (in case we're among natural endpoints) and hint will be not submitted to other endpoints. -- This message was sent by Atlassian JIRA (v6.2#6252)
