[jira] [Resolved] (CASSANDRA-9075) Learning to submit Cassandra Jiras through an example
[ https://issues.apache.org/jira/browse/CASSANDRA-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laura Adney resolved CASSANDRA-9075. Resolution: Fixed Was not meant to be saved. > Learning to submit Cassandra Jiras through an example > - > > Key: CASSANDRA-9075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9075 > Project: Cassandra > Issue Type: Bug >Reporter: Laura Adney > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9075) Learning to submit Cassandra Jiras through an example
Laura Adney created CASSANDRA-9075: -- Summary: Learning to submit Cassandra Jiras through an example Key: CASSANDRA-9075 URL: https://issues.apache.org/jira/browse/CASSANDRA-9075 Project: Cassandra Issue Type: Bug Reporter: Laura Adney -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-7448) Query is successfully using a token() range that should not return data
Laura Adney created CASSANDRA-7448: -- Summary: Query is successfully using a token() range that should not return data Key: CASSANDRA-7448 URL: https://issues.apache.org/jira/browse/CASSANDRA-7448 Project: Cassandra Issue Type: Bug Reporter: Laura Adney Ran this on -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7023) Nodetool clearsnapshot should not remove all snapshots by default
[ https://issues.apache.org/jira/browse/CASSANDRA-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003597#comment-14003597 ] Laura Adney commented on CASSANDRA-7023: Want to add another point (business scenario) to this. When using snapshots for backup, administrators might do the following: Take a snapshot, for tape backups Repairs running at the same time, which adds an additional snapshot Do tape backup Clear snapshot The process runs the risk of removing a snapshot used for repairs as well as adding unwanted space to the backup. The process here is to help manage disk space in a manner that doesn't require a lot of complexity or additional management for snapshots created for repair versus snapshots created for backup. It would streamline the clear snapshot process to be able to exclude those snapshots that repair is using. > Nodetool clearsnapshot should not remove all snapshots by default > - > > Key: CASSANDRA-7023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7023 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Sucwinder Bassi >Priority: Minor > > Running a nodetool clearsnapshot will remove all snapshot files by default. > As this is removing data this shouldn't just go away and just remove all > snapshots. If you want to remove all snapshots there should be a force > option. A list option showing snapshots available would also be helpful which > could be piped into the nodetool clearsnapshot command. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7118) Exception around IOException doesnt report file or table getting exception
Laura Adney created CASSANDRA-7118: -- Summary: Exception around IOException doesnt report file or table getting exception Key: CASSANDRA-7118 URL: https://issues.apache.org/jira/browse/CASSANDRA-7118 Project: Cassandra Issue Type: Improvement Reporter: Laura Adney Priority: Minor Saw this in Cassandra version: 1.2.11.2 Run into several situations where an IOException indicates that corruption has occurred. The exception does not provide the sstable or the table name making it very difficult to determine what files are involved. The request is to update the error/exception to include more relevant table/file information. Example Exception: ERROR [ReadStage:146665] 2014-02-25 06:28:18,286 CassandraDaemon.java (line 191) Exception in thread Thread[ReadStage:146665,5,main] java.lang.RuntimeException: org.apache.cassandra.io.sstable.CorruptSSTableException: java.io.EOFException at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1613) 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) Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: java.io.EOFException Caused by: java.io.EOFException at java.io.RandomAccessFile.readFully(RandomAccessFile.java:446) at java.io.RandomAccessFile.readFully(RandomAccessFile.java:424) at org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:380) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:392) at org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:355) at org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:94) at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:92) at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:73) at org.apache.cassandra.db.columniterator.IndexedSliceReader$SimpleBlockFetcher.(IndexedSliceReader.java:477) at org.apache.cassandra.db.columniterator.IndexedSliceReader.(IndexedSliceReader.java:94) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6533) Denial of Service with get_slice operations
[
https://issues.apache.org/jira/browse/CASSANDRA-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laura Adney updated CASSANDRA-6533:
---
Attachment: stacktraces.txt
predicate_patch.txt
predAssertError (1).py
> Denial of Service with get_slice operations
> ---
>
> Key: CASSANDRA-6533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6533
> Project: Cassandra
> Issue Type: Bug
>Reporter: Laura Adney
> Attachments: predAssertError (1).py, predicate_patch.txt,
> stacktraces.txt
>
>
> We’ve come across a bug impacting Cassandra 1.2 and 2.0 with the potential to
> cause a denial of service condition in nodes handling get_slice requests.
> It appears that Cassandra does not check the length of a column name that is
> part of a range predicate for a *_slice query before it serialises the slice
> query to pass to the replicas. Names with a length greater than 0x cause
> an assertion error to occur in ByteBufferUtil.writeWithShortLength and a
> write a weird hint to the hinted handoff store.
> This further causes subsequent reads on the node to fail until Cassandra is
> restarted.
> 2.0.x does not appear to be affected by the Denial of Service condition,
> though probably warrants further investigation.
> The column name could be user controllable in certain applications and
> schemas, allowing a malicious user to stop all reads until the impacted nodes
> are restarted. Attached is a small python script (using pycassa) that will
> reproduce the issue on a fresh Cassandra cluster with more than one node with
> the following schema:
> CREATE KEYSPACE bar with placement_strategy =
> 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
> {replication_factor:2};
> use bar;
> CREATE COLUMN FAMILY Test1;
> It was tested against Cassandra 1.2.10, 1.2.12 and 2.0.3 on both OS X and
> Ubuntu (hasn't been tested against DSE). Included a rough patch that includes
> additional check in validatePredicate, however it hasn’t been formally tested
> other than a recompile and check to see if it prevents the assert error.
> predAssertError.py -> reproduce the bug on a fresh cluster (more than one
> node)
> stacktraces.txt (1.2.10 and 2.0.3 stack traces)
> predicate_patch.txt (diff of patch to fix issue)
> zd8209
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CASSANDRA-6533) Denial of Service with get_slice operations
Laura Adney created CASSANDRA-6533:
--
Summary: Denial of Service with get_slice operations
Key: CASSANDRA-6533
URL: https://issues.apache.org/jira/browse/CASSANDRA-6533
Project: Cassandra
Issue Type: Bug
Reporter: Laura Adney
We’ve come across a bug impacting Cassandra 1.2 and 2.0 with the potential to
cause a denial of service condition in nodes handling get_slice requests.
It appears that Cassandra does not check the length of a column name that is
part of a range predicate for a *_slice query before it serialises the slice
query to pass to the replicas. Names with a length greater than 0x cause an
assertion error to occur in ByteBufferUtil.writeWithShortLength and a write a
weird hint to the hinted handoff store.
This further causes subsequent reads on the node to fail until Cassandra is
restarted.
2.0.x does not appear to be affected by the Denial of Service condition, though
probably warrants further investigation.
The column name could be user controllable in certain applications and schemas,
allowing a malicious user to stop all reads until the impacted nodes are
restarted. Attached is a small python script (using pycassa) that will
reproduce the issue on a fresh Cassandra cluster with more than one node with
the following schema:
CREATE KEYSPACE bar with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
use bar;
CREATE COLUMN FAMILY Test1;
It was tested against Cassandra 1.2.10, 1.2.12 and 2.0.3 on both OS X and
Ubuntu (hasn't been tested against DSE). Included a rough patch that includes
additional check in validatePredicate, however it hasn’t been formally tested
other than a recompile and check to see if it prevents the assert error.
predAssertError.py -> reproduce the bug on a fresh cluster (more than one node)
stacktraces.txt (1.2.10 and 2.0.3 stack traces)
predicate_patch.txt (diff of patch to fix issue)
zd8209
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CASSANDRA-6460) adjust sstableloader to accept a collection field for update
Laura Adney created CASSANDRA-6460:
--
Summary: adjust sstableloader to accept a collection field for
update
Key: CASSANDRA-6460
URL: https://issues.apache.org/jira/browse/CASSANDRA-6460
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Laura Adney
Currently in sstableloader (Cassandra version 1.2) there is not a way to
specify an action for a field that is a collection. So an update parameter
might be useful in some cases where you dont want to overwrite the collection
in a row, but you want to add what ever is coming in, into the collection.
So in cqlsh you would do:
UPDATE users
SET emails = emails + {'f...@friendsofmordor.org'} WHERE user_id = 'frodo';
Is there a way to emulate that with the bulk loader?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6036) When SStableloader exits, allow for a non-zero exit code if an exception is encounterd
[ https://issues.apache.org/jira/browse/CASSANDRA-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768897#comment-13768897 ] Laura Adney commented on CASSANDRA-6036: It says DSE 3.1.3. I havent tested, so I will do a test on it. Laura > When SStableloader exits, allow for a non-zero exit code if an exception is > encounterd > -- > > Key: CASSANDRA-6036 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6036 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Laura Adney > > Request from customer to have sstableloader exit with non-zero exit code when > an exception is encountered. > Customer reports:1379107056.40 ERROR [Thread-108] 2013-09-13 17:17:36,344 > CassandraDaemon.java (line 192) Exception in thread Thread[Thread-108,5,main] > 1379107056.40 java.lang.AssertionError > 1379107056.40 at > org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:168) > 1379107056.40 at > org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:138) > 1379107056.40 at > org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238) > 1379107056.40 at > org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178) > 1379107056.40 at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78) > 1379107056.40 ERROR [Thread-108] 17:17:36,344 Exception in thread > Thread[Thread-108,5,main] > 1379107056.40 java.lang.AssertionError > 1379107056.40 at > org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:168) > 1379107056.40 at > org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:138) > 1379107056.40 at > org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238) > 1379107056.40 at > org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178) > 1379107056.40 at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78) > And finally: sstableloader exits 0 in this condition, as opposed to non-zero, > so our tools blindly pass over this and don't realize that the import failed. > That's pretty bad, too. > zd6699 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-6036) When SStableloader exits, allow for a non-zero exit code if an exception is encounterd
Laura Adney created CASSANDRA-6036: -- Summary: When SStableloader exits, allow for a non-zero exit code if an exception is encounterd Key: CASSANDRA-6036 URL: https://issues.apache.org/jira/browse/CASSANDRA-6036 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Laura Adney Request from customer to have sstableloader exit with non-zero exit code when an exception is encountered. Customer reports:1379107056.40 ERROR [Thread-108] 2013-09-13 17:17:36,344 CassandraDaemon.java (line 192) Exception in thread Thread[Thread-108,5,main] 1379107056.40 java.lang.AssertionError 1379107056.40 at org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:168) 1379107056.40 at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:138) 1379107056.40 at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238) 1379107056.40 at org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178) 1379107056.40 at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78) 1379107056.40 ERROR [Thread-108] 17:17:36,344 Exception in thread Thread[Thread-108,5,main] 1379107056.40 java.lang.AssertionError 1379107056.40 at org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:168) 1379107056.40 at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:138) 1379107056.40 at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238) 1379107056.40 at org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178) 1379107056.40 at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78) And finally: sstableloader exits 0 in this condition, as opposed to non-zero, so our tools blindly pass over this and don't realize that the import failed. That's pretty bad, too. zd6699 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
