[jira] [Commented] (CASSANDRA-10252) COPY FROM should respect time_format from cqlshrc
[
https://issues.apache.org/jira/browse/CASSANDRA-10252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020868#comment-15020868
]
cheng ren commented on CASSANDRA-10252:
---
The problem of using dateutil.parser is it can't distinguish MM/DD/ with
DD/MM/.
%z is only supported in python 3.2 later, otherwise it seems to me that there's
no easy way to parse %z.
> COPY FROM should respect time_format from cqlshrc
> -
>
> Key: CASSANDRA-10252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10252
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Carl Yeksigian
>Priority: Minor
> Labels: cqlsh, lhf
> Fix For: 2.1.x
>
>
> Currently, {{COPY FROM}} doesn't respect the {{time_format}} property in
> cqlshrc, we only use that for {{COPY TO}}. We should use the same property
> for both to prevent issues like CASSANDRA-8970.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10252) COPY FROM should respect time_format from cqlshrc
[
https://issues.apache.org/jira/browse/CASSANDRA-10252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020747#comment-15020747
]
Yunier Perez commented on CASSANDRA-10252:
--
I'm having some trouble to parse the date-time when %z is included in the time
format:
-
[http://stackoverflow.com/questions/1101508/how-to-parse-dates-with-0400-timezone-string-in-python]
-
[http://stackoverflow.com/questions/6571419/python-parsing-a-datetime-with-a-timezone]
Is it OK if I use the recommended *dateutil.parser*(third party lib) ??
> COPY FROM should respect time_format from cqlshrc
> -
>
> Key: CASSANDRA-10252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10252
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Carl Yeksigian
>Priority: Minor
> Labels: cqlsh, lhf
> Fix For: 2.1.x
>
>
> Currently, {{COPY FROM}} doesn't respect the {{time_format}} property in
> cqlshrc, we only use that for {{COPY TO}}. We should use the same property
> for both to prevent issues like CASSANDRA-8970.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10747) CQL.textile syntax incorrectly includes optional keyspace for aggregate SFUNC and FINALFUNC
[
https://issues.apache.org/jira/browse/CASSANDRA-10747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-10747:
-
Attachment: 10747.txt
Attached patch fixes the doc?
Someone available for a review?
> CQL.textile syntax incorrectly includes optional keyspace for aggregate SFUNC
> and FINALFUNC
> ---
>
> Key: CASSANDRA-10747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10747
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation and Website
>Reporter: dan jatnieks
>Assignee: Robert Stupp
>Priority: Trivial
> Attachments: 10747.txt
>
>
> [CQL.textile|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile]
> incorrectly includes an optional keyspace for the {{SFUNC}} and
> {{FINALFUNC}} parts of a {{CREATE AGGREGATE}} statement.
> The grammar for 2.2 and 3.0 does not allow a keyspace to be specified here.
> From the CQL.textile:
> {noformat}
> ::= CREATE ( OR REPLACE )?
> AGGREGATE ( IF NOT EXISTS )?
> ( '.' )?
> '(' ( ',' )* ')'
> SFUNC ( '.' )?
> STYPE
> ( FINALFUNC ( '.' )?
> )?
> ( INITCOND )?
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10747) CQL.textile syntax incorrectly includes optional keyspace for aggregate SFUNC and FINALFUNC
[
https://issues.apache.org/jira/browse/CASSANDRA-10747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020624#comment-15020624
]
Robert Stupp edited comment on CASSANDRA-10747 at 11/21/15 7:14 PM:
Attached patch fixes the doc.
Someone available for a review?
was (Author: snazy):
Attached patch fixes the doc?
Someone available for a review?
> CQL.textile syntax incorrectly includes optional keyspace for aggregate SFUNC
> and FINALFUNC
> ---
>
> Key: CASSANDRA-10747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10747
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation and Website
>Reporter: dan jatnieks
>Assignee: Robert Stupp
>Priority: Trivial
> Attachments: 10747.txt
>
>
> [CQL.textile|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile]
> incorrectly includes an optional keyspace for the {{SFUNC}} and
> {{FINALFUNC}} parts of a {{CREATE AGGREGATE}} statement.
> The grammar for 2.2 and 3.0 does not allow a keyspace to be specified here.
> From the CQL.textile:
> {noformat}
> ::= CREATE ( OR REPLACE )?
> AGGREGATE ( IF NOT EXISTS )?
> ( '.' )?
> '(' ( ',' )* ')'
> SFUNC ( '.' )?
> STYPE
> ( FINALFUNC ( '.' )?
> )?
> ( INITCOND )?
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10747) CQL.textile syntax incorrectly includes optional keyspace for aggregate SFUNC and FINALFUNC
[
https://issues.apache.org/jira/browse/CASSANDRA-10747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp reassigned CASSANDRA-10747:
Assignee: Robert Stupp
> CQL.textile syntax incorrectly includes optional keyspace for aggregate SFUNC
> and FINALFUNC
> ---
>
> Key: CASSANDRA-10747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10747
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation and Website
>Reporter: dan jatnieks
>Assignee: Robert Stupp
>Priority: Trivial
>
> [CQL.textile|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile]
> incorrectly includes an optional keyspace for the {{SFUNC}} and
> {{FINALFUNC}} parts of a {{CREATE AGGREGATE}} statement.
> The grammar for 2.2 and 3.0 does not allow a keyspace to be specified here.
> From the CQL.textile:
> {noformat}
> ::= CREATE ( OR REPLACE )?
> AGGREGATE ( IF NOT EXISTS )?
> ( '.' )?
> '(' ( ',' )* ')'
> SFUNC ( '.' )?
> STYPE
> ( FINALFUNC ( '.' )?
> )?
> ( INITCOND )?
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10743) Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
[
https://issues.apache.org/jira/browse/CASSANDRA-10743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020584#comment-15020584
]
Gábor Auth commented on CASSANDRA-10743:
I've removed the schema.ddl.gz, it is not DDL specific issue.
> Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
>
>
> Key: CASSANDRA-10743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10743
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS Linux release 7.1.1503, OpenJDK Runtime
> Environment (build 1.8.0_65-b17), DSC Cassandra 3.0.0 (tar.gz)
>Reporter: Gábor Auth
> Attachments: faulty-tables.tar.gz
>
>
> {code}
> [cassandra@dc01-rack01-cass01 ~]$
> /home/cassandra/dsc-cassandra-3.0.0/bin/nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.rows.CellPath$EmptyCellPath.get(CellPath.java:143)
> at
> org.apache.cassandra.db.marshal.CollectionType$CollectionPathSerializer.serializedSize(CollectionType.java:226)
> at
> org.apache.cassandra.db.rows.BufferCell$Serializer.serializedSize(BufferCell.java:325)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.sizeOfComplexColumn(UnfilteredSerializer.java:297)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:282)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:163)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:144)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:112)
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:121)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:397)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10743) Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
[
https://issues.apache.org/jira/browse/CASSANDRA-10743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gábor Auth updated CASSANDRA-10743:
---
Attachment: (was: schema.ddl.gz)
> Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
>
>
> Key: CASSANDRA-10743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10743
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS Linux release 7.1.1503, OpenJDK Runtime
> Environment (build 1.8.0_65-b17), DSC Cassandra 3.0.0 (tar.gz)
>Reporter: Gábor Auth
> Attachments: faulty-tables.tar.gz
>
>
> {code}
> [cassandra@dc01-rack01-cass01 ~]$
> /home/cassandra/dsc-cassandra-3.0.0/bin/nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.rows.CellPath$EmptyCellPath.get(CellPath.java:143)
> at
> org.apache.cassandra.db.marshal.CollectionType$CollectionPathSerializer.serializedSize(CollectionType.java:226)
> at
> org.apache.cassandra.db.rows.BufferCell$Serializer.serializedSize(BufferCell.java:325)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.sizeOfComplexColumn(UnfilteredSerializer.java:297)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:282)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:163)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:144)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:112)
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:121)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:397)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10743) Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
[
https://issues.apache.org/jira/browse/CASSANDRA-10743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gábor Auth updated CASSANDRA-10743:
---
Attachment: faulty-tables.tar.gz
I've removed some (2-3 fileset per node) files (like the attached fileset) and
the `nodetool upgradesstables` converted all files (la-*) to the new format
(ma-*). The question is: what is these empty files and the version 2.2.2 why
works? :)
> Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
>
>
> Key: CASSANDRA-10743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10743
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS Linux release 7.1.1503, OpenJDK Runtime
> Environment (build 1.8.0_65-b17), DSC Cassandra 3.0.0 (tar.gz)
>Reporter: Gábor Auth
> Attachments: faulty-tables.tar.gz, schema.ddl.gz
>
>
> {code}
> [cassandra@dc01-rack01-cass01 ~]$
> /home/cassandra/dsc-cassandra-3.0.0/bin/nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.rows.CellPath$EmptyCellPath.get(CellPath.java:143)
> at
> org.apache.cassandra.db.marshal.CollectionType$CollectionPathSerializer.serializedSize(CollectionType.java:226)
> at
> org.apache.cassandra.db.rows.BufferCell$Serializer.serializedSize(BufferCell.java:325)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.sizeOfComplexColumn(UnfilteredSerializer.java:297)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:282)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:163)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:144)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:112)
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:121)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:397)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020444#comment-15020444 ] Ivan Burmistrov commented on CASSANDRA-10585: - I've reattached patch for 2.2: I've added the ability to consider 0 values in EstimatedHistogram and SSTablesPerReadHistogram uses this ability now. If it is OK, I will prepare patches for 3.0 and trunk. > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: (was: SSTablePerReadHistogram_RowCache-cassandra-3_0.patch) > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: SSTablePerReadHistogram_RowCache-cassandra-2_2.patch > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: (was: SSTablePerReadHistogram_RowCache-cassandra-2_2.patch) > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10743) Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
[
https://issues.apache.org/jira/browse/CASSANDRA-10743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020317#comment-15020317
]
Gábor Auth commented on CASSANDRA-10743:
I've tried to upgrade with the sstableupgrade tool:
{code}
[cassandra@dc01-rack01-cass02 ~]$
/home/cassandra/dsc-cassandra-3.0.0/bin/sstableupgrade gacivstest20141213
workqueueitems_by_city
WARN 07:46:30 Only 39708 MB free across all data volumes. Consider adding more
capacity to your cluster or removing obsolete snapshots
Found 1 sstables that need upgrading.
Exception in thread "main" java.lang.AssertionError: length is not > 0: 0
at
org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:408)
at
org.apache.cassandra.io.sstable.metadata.CompactionMetadata$CompactionMetadataSerializer.deserialize(CompactionMetadata.java:93)
at
org.apache.cassandra.io.sstable.metadata.CompactionMetadata$CompactionMetadataSerializer.deserialize(CompactionMetadata.java:73)
at
org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:123)
at
org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:94)
at
org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:102)
at
org.apache.cassandra.io.sstable.format.SSTableReader.getApproximateKeyCount(SSTableReader.java:256)
at org.apache.cassandra.db.compaction.Upgrader.(Upgrader.java:63)
at
org.apache.cassandra.tools.StandaloneUpgrader.main(StandaloneUpgrader.java:107)
WARN 07:46:33 Failed trySkipCache on file:
dsc-cassandra-3.0.0/bin/../data/data/gacivstest20141213/workqueueitems_by_city-9873aa1082c611e48defa5ddfeca06b6/la-1542-big-Data.db
Error: Bad file descriptor
{code}
> Failed upgradesstables (upgrade from 2.2.2 to 3.0.0)
>
>
> Key: CASSANDRA-10743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10743
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS Linux release 7.1.1503, OpenJDK Runtime
> Environment (build 1.8.0_65-b17), DSC Cassandra 3.0.0 (tar.gz)
>Reporter: Gábor Auth
> Attachments: schema.ddl.gz
>
>
> {code}
> [cassandra@dc01-rack01-cass01 ~]$
> /home/cassandra/dsc-cassandra-3.0.0/bin/nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.rows.CellPath$EmptyCellPath.get(CellPath.java:143)
> at
> org.apache.cassandra.db.marshal.CollectionType$CollectionPathSerializer.serializedSize(CollectionType.java:226)
> at
> org.apache.cassandra.db.rows.BufferCell$Serializer.serializedSize(BufferCell.java:325)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.sizeOfComplexColumn(UnfilteredSerializer.java:297)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:282)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:163)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:144)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:112)
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:121)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:397)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Th
