[jira] [Updated] (CASSANDRA-7997) Improve the ability to run the CassandraDaemon as a managed service
[ https://issues.apache.org/jira/browse/CASSANDRA-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heiko Braun updated CASSANDRA-7997: --- Attachment: (was: CASSANDRA-7998.txt) > Improve the ability to run the CassandraDaemon as a managed service > --- > > Key: CASSANDRA-7997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7997 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Heiko Braun >Priority: Minor > > See a transcript of the discussion here: > http://www.mail-archive.com/dev@cassandra.apache.org/msg07529.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7997) Improve the ability to run the CassandraDaemon as a managed service
[ https://issues.apache.org/jira/browse/CASSANDRA-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heiko Braun updated CASSANDRA-7997: --- Attachment: (was: CASSANDRA-8003.txt) > Improve the ability to run the CassandraDaemon as a managed service > --- > > Key: CASSANDRA-7997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7997 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Heiko Braun >Priority: Minor > > See a transcript of the discussion here: > http://www.mail-archive.com/dev@cassandra.apache.org/msg07529.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7872) ensure compacted obsolete sstables are not open on node restart and nodetool refresh, even on sstable reference miscounting or deletion tasks are failed.
[ https://issues.apache.org/jira/browse/CASSANDRA-7872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160039#comment-14160039 ] Oleg Anastasyev edited comment on CASSANDRA-7872 at 10/6/14 7:01 AM: - Pavel, this is not happens to work, this is just how CMS work since the very beginning. The weak proc stage is explaned in this old blog post of Oracle back in 2006. https://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs for example. If you google, you can find more. If you check out the code of the hotspot, you can find it there. If youre curious, you can find this stage on G1 mixed cycle as well. I can hardly believe that Oracle will ever remove weak refs processing from concurrent GC cycles. This is just meaningless. Just because you did not made PhRefs work for some purpose in past does not mean it cannot be used for all purposes ever. In your case, you arguing with, this could be JVM with a bug or you may just had bug in your code, which prevented PhRef to work as intended. Until you specify exact version of JDK you was using, it is hard to tell was it bug, behavior of that exact JVM or just bug in your code. By the way, claiming that "FullGC never happens on C*" as an argument against #3 is not legal as well, because you cannot point out some "spec like JMM", that Full GC never happens on CMS as well. Moreover, it is explicitly known, that it does happen on any CMS instance, regardless of how hard you try. So even in worst case, using that JDK, version of which you cannot recon now, with possibly broken standard JVM behavior, it will delete files from disk earlier than restart of a node. And this is the exact purpose of #3 - just to remove it earlier that restart. Currently, on 2.0 on a 64 node cluster we have is a couple of tens sstable removals performed by PhRef queue thread instead of a ref counting algo. (this all happens at night repairs, so i suspect a bug there). So not having #3 you are not and will not be even aware of the problem. was (Author: m0nstermind): Pavel, this is not happens to work, this is just how CMS work since the very beginning. The weak proc stage is explaned in this old blog post of Oracle back in 2006. https://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs for example. If you google, you can find more. If you check out the code of the hotspot, you can find it there. If youre curious, you can find this stage on G1 mixed cycle as well. I can hardly believe that Oracle will ever remove weak refs processing from concurrent GC cycles. This is just meaningless. Just because you did not made PhRefs work for some purpose in past does not mean it cannot be used for all purposes ever. In your case, you arguing with, this could be JVM with a bug or you may just had bug in your code, which prevented PhRef to work as intended. Until you specify exact version of JDK you was using, it is hard to tell was it bug, behavior of that exact JVM or just bug in your code. By the way, claiming that "FullGC never happens on C*" as an argument against #3 is not legal as well, because you cannot point out some "spec like JMM", that Full GC never happens on CMS as well. Moreover, it is explicitly known, that it does happen on any CMS instance, regardless of how hard you try. So even in worst case, using that JDK, version of which you cannot recon now, with possibly broken standard JVM behavior, it will delete files from disk earlier than restart of a node. And this is the exact purpose of #3 - just to remove it earlier that restart. > ensure compacted obsolete sstables are not open on node restart and nodetool > refresh, even on sstable reference miscounting or deletion tasks are failed. > - > > Key: CASSANDRA-7872 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7872 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Oleg Anastasyev >Assignee: Oleg Anastasyev > Fix For: 2.0.11 > > Attachments: EnsureNoObsoleteSSTables-7872-v2.0.txt > > > Since CASSANDRA-4436 compacted sstables are no more marked with > COMPACTED_MARKER file. Instead after they are compacted, DataTracker calls > SSTableReader.markObsolete(), but the actual deletion is happening later on > SSTableReader.releaseReference(). > This reference counting is very fragile, it is very easy to introduce a > hard-to-catch and rare bug, so this reference count never reaches 0 ( like > CASSANDRA-6503 for example ) > This means, that very rarely obsolete sstable files are not removed from disk > (but are not used anymore by cassandra to read data). > If more than gc grace time has pas
[jira] [Updated] (CASSANDRA-7997) Improve the ability to run the CassandraDaemon as a managed service
[ https://issues.apache.org/jira/browse/CASSANDRA-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heiko Braun updated CASSANDRA-7997: --- Attachment: CASSANDRA-8003.txt CASSANDRA-7998.txt Updated patches, incorporating brandon's comments > Improve the ability to run the CassandraDaemon as a managed service > --- > > Key: CASSANDRA-7997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7997 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Heiko Braun >Priority: Minor > Attachments: CASSANDRA-7998.txt, CASSANDRA-8003.txt > > > See a transcript of the discussion here: > http://www.mail-archive.com/dev@cassandra.apache.org/msg07529.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7872) ensure compacted obsolete sstables are not open on node restart and nodetool refresh, even on sstable reference miscounting or deletion tasks are failed.
[ https://issues.apache.org/jira/browse/CASSANDRA-7872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160086#comment-14160086 ] Pavel Yaskevich commented on CASSANDRA-7872: I am not sure why are you trying to twist my words here, I didn't ever claim that FullGC never happens with C* rather that we trying our best to reduce frequency of it to minimum. My concern here is, as already stated, that #3 is intended as a safety net feature but we are trying to rely on implementation detail which is never a good design, even tho it's currently this way it doesn't mean it's here to say or works the same across the platforms and garbage collectors, it's always better to address the problem instead of trying to fix it's sympthoms. That said, if other people think it's a good idea I would comply. > ensure compacted obsolete sstables are not open on node restart and nodetool > refresh, even on sstable reference miscounting or deletion tasks are failed. > - > > Key: CASSANDRA-7872 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7872 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Oleg Anastasyev >Assignee: Oleg Anastasyev > Fix For: 2.0.11 > > Attachments: EnsureNoObsoleteSSTables-7872-v2.0.txt > > > Since CASSANDRA-4436 compacted sstables are no more marked with > COMPACTED_MARKER file. Instead after they are compacted, DataTracker calls > SSTableReader.markObsolete(), but the actual deletion is happening later on > SSTableReader.releaseReference(). > This reference counting is very fragile, it is very easy to introduce a > hard-to-catch and rare bug, so this reference count never reaches 0 ( like > CASSANDRA-6503 for example ) > This means, that very rarely obsolete sstable files are not removed from disk > (but are not used anymore by cassandra to read data). > If more than gc grace time has passed since sstable file was not removed from > disk and operator issues either nodetool refresh or just reboots a node, > these obsolete files are being discovered and open for read by a node. So > deleted data is resurrected, being quickly spread by RR to whole cluster. > Because consequences are very serious (even a single not removed obsolete > sstable file could render your data useless) this patch makes sure no > obsolete sstable file can be open for read by: > 1. Removing sstables on CFS init analyzing sstable generations (sstable is > removed, if there are another sstable, listing this as ancestor) > 2. Reimplementing COMPACTED_MARKER file for sstable. This marker is created > as soon as markObsolete is called. This is neccessary b/c generation info can > be lost (when sstables compact to none) > 3. To remove sstables sooner then restart - reimplemented the good old GC > phantom reference queue as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8048) Add WARN for large rows
[ https://issues.apache.org/jira/browse/CASSANDRA-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hattrell updated CASSANDRA-8048: - Description: Similarly to how we warn on excessive tombstones or large batches - it would be useful to warn if we come across a large row over a specific threshold. If not too intrusive it could provide us with a smoking gun for gc thrashing type issues. To put some meat on the bones - I've recently seen someone store a 1Gb blob and then try to work round it by splitting it into 3 columns of 330 Mb each. Neither gave particularly good performance. On the opposite side of the coin - a large number of columns grabbed at once can also lead to problems. was: Similarly to how we warn on excessive tombstones or large batches - it would be useful to warn if we come across a wide row over a specific threshold. If not too intrusive it could provide us with a smoking gun for gc thrashing type issues. Summary: Add WARN for large rows (was: Add WARN for wide rows) > Add WARN for large rows > --- > > Key: CASSANDRA-8048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8048 > Project: Cassandra > Issue Type: New Feature >Reporter: Adam Hattrell > > Similarly to how we warn on excessive tombstones or large batches - it would > be useful to warn if we come across a large row over a specific threshold. > If not too intrusive it could provide us with a smoking gun for gc thrashing > type issues. > To put some meat on the bones - I've recently seen someone store a 1Gb blob > and then try to work round it by splitting it into 3 columns of 330 Mb each. > Neither gave particularly good performance. > On the opposite side of the coin - a large number of columns grabbed at once > can also lead to problems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7990) CompoundDenseCellNameType AssertionError and BoundedComposite to CellName ClasCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-7990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160097#comment-14160097
]
Sylvain Lebresne commented on CASSANDRA-7990:
-
lgtm, +1
> CompoundDenseCellNameType AssertionError and BoundedComposite to CellName
> ClasCastException
> ---
>
> Key: CASSANDRA-7990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7990
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu, Java 1.7.0_67, Cassandra 2.1.0,
> cassandra-driver-core:jar:2.0.6
>Reporter: Christian Spriegel
>Assignee: Tyler Hobbs
>Priority: Minor
> Fix For: 2.1.1
>
> Attachments: 7990-partial-fix.txt, 7990.txt
>
>
> I just updated my laptop to Cassandra 2.1 and created a fresh data folder.
> When trying to run my automated tests i get a lot these exceptions in the
> Cassandra log:
> {code}
> ERROR [SharedPool-Worker-1] 2014-09-23 12:59:17,812 ErrorMessage.java:218 -
> Unexpected exception during request
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.composites.CompoundDenseCellNameType.create(CompoundDenseCellNameType.java:57)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.Constants$Setter.execute(Constants.java:313)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.UpdateStatement.addUpdateForKey(UpdateStatement.java:91)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.BatchStatement.addStatementMutations(BatchStatement.java:235)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.BatchStatement.getMutations(BatchStatement.java:181)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:283)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:269)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:264)
> ~[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.process(QueryProcessor.java:206)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:118)
> ~[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(Executors.java:471)
> [na:1.7.0_67]
> 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(Thread.java:745) [na:1.7.0_67]
> ERROR [Thrift:9] 2014-09-23 12:59:17,823 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.lang.ClassCastException:
> org.apache.cassandra.db.composites.BoundedComposite cannot be cast to
> org.apache.cassandra.db.composites.CellName
> at
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:170)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.thrift.CassandraServer.deleteColumnOrSuperColumn(CassandraServer.java:936)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:860)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:971)
> ~[apache
[jira] [Commented] (CASSANDRA-8058) local consistency level during boostrap (may cause a write timeout on each write request)
[
https://issues.apache.org/jira/browse/CASSANDRA-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160100#comment-14160100
]
Nicolas DOUILLET commented on CASSANDRA-8058:
-
In the same topic, I think that something else is not consistent, on
bootstrapping, concerning the Unavailability.
In {{org.apache.cassandra.db.ConsistencyLevel#assureSufficientLiveNodes}} we're
using the concatenation of the natural endpoints and the pending endpoints to
determine whether there is enough alive nodes.
The number of required nodes, in that case, is only based on the table
configuration and the consistency level.
However, later, in order to validate a write request, the way we compute the
number of required nodes is slightly different because we're adding the number
of pending nodes.
I think that, during a bootstrap, some requests may end with a timeout, while
they could/would had been detected as unavailable before.
> local consistency level during boostrap (may cause a write timeout on each
> write request)
> -
>
> Key: CASSANDRA-8058
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8058
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Nicolas DOUILLET
>Priority: Critical
> Fix For: 1.2.19
>
> Attachments:
> 0001-during-boostrap-block-only-for-local-pending-endpoin.patch.txt
>
>
> Hi,
> During bootstrap, for {{LOCAL_QUORUM}} and {{LOCAL_ONE}} consistencies, the
> {{DatacenterWriteResponseHandler}} were waiting for pending remote endpoints.
> I think that's a regression, because it seems that it has been correctly
> implemented in CASSANDRA-833, but removed later.
> It was specifically annoying in the case of {{RF=2}} and {{cl=LOCAL_QUORUM}},
> because during a bootstrap of a remote node, all requests ended in
> {{WriteTimeout}}, because they were waiting for a response that would never
> happen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7734) Schema pushes (seemingly) randomly not happening
[
https://issues.apache.org/jira/browse/CASSANDRA-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160104#comment-14160104
]
Marcus Eriksson commented on CASSANDRA-7734:
+1
> Schema pushes (seemingly) randomly not happening
>
>
> Key: CASSANDRA-7734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7734
> Project: Cassandra
> Issue Type: Bug
>Reporter: graham sanderson
>Assignee: Aleksey Yeschenko
> Fix For: 2.0.11, 2.1.1
>
> Attachments: 7734.txt
>
>
> We have been seeing problems since upgrade to 2.0.9 from 2.0.5.
> Basically after a while, new schema changes (we periodically add tables)
> start propagating very slowly to some nodes and fast to others. It looks from
> the logs and trace that in this case the "push" of the schema never happens
> (note a node has decided not to push to another node, it doesn't seem to
> start again) from the originating node to some of the other nodes. In this
> case though, we do see the other node end up pulling the schema some time
> later when it notices its schema is out of date.
> Here is code from 2.0.9 MigrationManager.announce
> {code}
>for (InetAddress endpoint : Gossiper.instance.getLiveMembers())
> {
> // only push schema to nodes with known and equal versions
> if (!endpoint.equals(FBUtilities.getBroadcastAddress()) &&
> MessagingService.instance().knowsVersion(endpoint) &&
> MessagingService.instance().getRawVersion(endpoint) ==
> MessagingService.current_version)
> pushSchemaMutation(endpoint, schema);
> }
> {code}
> and from 2.0.5
> {code}
> for (InetAddress endpoint : Gossiper.instance.getLiveMembers())
> {
> if (endpoint.equals(FBUtilities.getBroadcastAddress()))
> continue; // we've dealt with localhost already
> // don't send schema to the nodes with the versions older than
> current major
> if (MessagingService.instance().getVersion(endpoint) <
> MessagingService.current_version)
> continue;
> pushSchemaMutation(endpoint, schema);
> }
> {code}
> the old getVersion() call would return MessagingService.current_version if
> the version was unknown, so the push would occur in this case. I don't have
> logging to prove this, but have strong suspicion that the version may end up
> null in some cases (which would have allowed schema propagation in 2.0.5, but
> not by somewhere after that and <= 2.0.9)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7692) Upgrade Cassandra Java Driver to 2.1
[ https://issues.apache.org/jira/browse/CASSANDRA-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160109#comment-14160109 ] Sylvain Lebresne commented on CASSANDRA-7692: - I'm afraid copying everything (option 3 above) is the idea I like the least as that remove the main point of reusing existing code. I'd suggested we not overthink it and start simple by just including the 3.0 patch above (let's wait until people report problems before trying to fix them). More generally, conflicts between C* depencies and potential dependencies of application that use C* embedded can always happen but we can't remove all dependencies because of that. But regarding netty versions, the current driver use version 3 while C* uses version 4 but I'm not sure it's such a problem in practice since those netty versions use different package names. Further, I'm confident the java driver will be updated to netty 4 by the time C* 3.0 is out so we ultimately won't have multiple versions. > Upgrade Cassandra Java Driver to 2.1 > > > Key: CASSANDRA-7692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7692 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp > Fix For: 3.0 > > Attachments: 7692-2.1.txt, 7692-3.0.txt, 7692-3.0v2.txt > > > UDFs (CASSANDRA-7563) requires Java Driver that supports User Types and new > collection features (at least Java Driver 2.1). > May also be handled separately if e.g. Hadoop stuff requires this (follow-up > to CASSANDRA-7618). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8004) Run LCS for both repaired and unrepaired data
[ https://issues.apache.org/jira/browse/CASSANDRA-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson reassigned CASSANDRA-8004: -- Assignee: Marcus Eriksson > Run LCS for both repaired and unrepaired data > - > > Key: CASSANDRA-8004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8004 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Labels: compaction > Fix For: 2.1.1 > > > If a user has leveled compaction configured, we should run that for both the > unrepaired and the repaired data. I think this would make things a lot easier > for end users > It would simplify migration to incremental repairs as well, if a user runs > incremental repair on its nice leveled unrepaired data, we wont need to drop > it all to L0, instead we can just start moving sstables from the unrepaired > leveling straight into the repaired leveling > Idea could be to have two instances of LeveledCompactionStrategy and move > sstables between the instances after an incremental repair run (and let LCS > be totally oblivious to whether it handles repaired or unrepaired data). Same > should probably apply to any compaction strategy, run two instances and > remove all repaired/unrepaired logic from the strategy itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6382) Allow indexing nested types
[ https://issues.apache.org/jira/browse/CASSANDRA-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160125#comment-14160125 ] Sylvain Lebresne commented on CASSANDRA-6382: - bq. Is there a follow-up ticket for nested fields inside collections? There isn't. And fyi, the current plan as far as I can tell is that we'll see "later" if we want to go there (it's in nobody's pipeline if you prefer). > Allow indexing nested types > --- > > Key: CASSANDRA-6382 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6382 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne > Labels: cql > Fix For: 2.1.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6602) Compaction improvements to optimize time series data
[ https://issues.apache.org/jira/browse/CASSANDRA-6602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160131#comment-14160131 ] Marcus Eriksson commented on CASSANDRA-6602: (epic writeup, hope you can reuse most of it in your thesis report) bq. if you run DTCS from the start, it won't matter what timestamp you chose as the representative timestamp of an SSTable. I think we should have a way for people to go from LCS/STCS to DTCS, probably using CASSANDRA-7019 - ie change to DTCS, run a 7019-major compaction and you should have your data "date tiered". bq. The current implementation favors compacting and recompacting them as much as possible for the first hour (but not if they're less than min_compaction_threshold). I think this is the way to go, I imagine one of the most common queries to be "give me the last hour" of data, keeping a limit to the amount of sstables there should be beneficial. We should also note that currently the newest data will always be size tiered due to the way incremental repairs are handled, I hope to change this in CASSANDRA-8004, then we will run 2 instances of the compaction strategy and move sstables between them instead of running DTCS only for repaired data (and STCS for unrepaired data, which should be the newest set of sstables). I'd say we should put this in 2.1 since it doesn't touch anything outside of the compaction strategy, WDYT [~jbellis] ? Maybe label is as 'experimental' if we want to hint to users that they should test a bit more carefully etc. > Compaction improvements to optimize time series data > > > Key: CASSANDRA-6602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6602 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Tupshin Harper >Assignee: Björn Hegerfors > Labels: compaction, performance > Fix For: 3.0 > > Attachments: 1 week.txt, 8 weeks.txt, STCS 16 hours.txt, > TimestampViewer.java, > cassandra-2.0-CASSANDRA-6602-DateTieredCompactionStrategy.txt, > cassandra-2.0-CASSANDRA-6602-DateTieredCompactionStrategy_v2.txt, > cassandra-2.0-CASSANDRA-6602-DateTieredCompactionStrategy_v3.txt > > > There are some unique characteristics of many/most time series use cases that > both provide challenges, as well as provide unique opportunities for > optimizations. > One of the major challenges is in compaction. The existing compaction > strategies will tend to re-compact data on disk at least a few times over the > lifespan of each data point, greatly increasing the cpu and IO costs of that > write. > Compaction exists to > 1) ensure that there aren't too many files on disk > 2) ensure that data that should be contiguous (part of the same partition) is > laid out contiguously > 3) deleting data due to ttls or tombstones > The special characteristics of time series data allow us to optimize away all > three. > Time series data > 1) tends to be delivered in time order, with relatively constrained exceptions > 2) often has a pre-determined and fixed expiration date > 3) Never gets deleted prior to TTL > 4) Has relatively predictable ingestion rates > Note that I filed CASSANDRA-5561 and this ticket potentially replaces or > lowers the need for it. In that ticket, jbellis reasonably asks, how that > compaction strategy is better than disabling compaction. > Taking that to heart, here is a compaction-strategy-less approach that could > be extremely efficient for time-series use cases that follow the above > pattern. > (For context, I'm thinking of an example use case involving lots of streams > of time-series data with a 5GB per day ingestion rate, and a 1000 day > retention with TTL, resulting in an eventual steady state of 5TB per node) > 1) You have an extremely large memtable (preferably off heap, if/when doable) > for the table, and that memtable is sized to be able to hold a lengthy window > of time. A typical period might be one day. At the end of that period, you > flush the contents of the memtable to an sstable and move to the next one. > This is basically identical to current behaviour, but with thresholds > adjusted so that you can ensure flushing at predictable intervals. (Open > question is whether predictable intervals is actually necessary, or whether > just waiting until the huge memtable is nearly full is sufficient) > 2) Combine the behaviour with CASSANDRA-5228 so that sstables will be > efficiently dropped once all of the columns have. (Another side note, it > might be valuable to have a modified version of CASSANDRA-3974 that doesn't > bother storing per-column TTL since it is required that all columns have the > same TTL) > 3) Be able to mark column families as read/write only (no explicit deletes), > s
[jira] [Updated] (CASSANDRA-8054) EXECUTE request with skipMetadata=false gets no metadata in response
[
https://issues.apache.org/jira/browse/CASSANDRA-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-8054:
Attachment: 8054-v2.txt
[This
comment|https://issues.apache.org/jira/browse/CASSANDRA-7120?focusedCommentId=14005790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14005790]
on CASSANDRA-7120 applies here as well, we have to copy the whole metadata,
not just the {{names}}. On CASSANDRA-7120 I advocated for saving the allocation
of a new Metatdata object when there is no paging state, but extending this to
this case is probably a bit more dangerous than anything else, so attaching
patch that somewhat revert CASSANDRA-7120 solution and copy the whole metadata
instead.
> EXECUTE request with skipMetadata=false gets no metadata in response
>
>
> Key: CASSANDRA-8054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8054
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Olivier Michallat
> Attachments: 8054-2.1.txt, 8054-v2.txt
>
>
> This has been reported independently with the
> [Java|https://datastax-oss.atlassian.net/browse/JAVA-482] and
> [C++|https://datastax-oss.atlassian.net/browse/CPP-174] drivers.
> This happens under heavy load, where multiple client threads prepare and
> execute statements in parallel. One of them sends an EXECUTE request with
> skipMetadata=false, but the returned ROWS response has no metadata in it.
> A patch of {{Message.Dispatcher.channelRead0}} confirmed that the flag was
> incorrectly set on the response:
> {code}
> logger.debug("Received: {}, v={}", request,
> connection.getVersion());
> boolean skipMetadataOnRequest = false;
> if (request instanceof ExecuteMessage) {
> ExecuteMessage execute = (ExecuteMessage)request;
> skipMetadataOnRequest = execute.options.skipMetadata();
> }
> response = request.execute(qstate);
> if (request instanceof ExecuteMessage) {
> Rows rows = (Rows)response;
> boolean skipMetadataOnResponse =
> rows.result.metadata.flags.contains(Flag.NO_METADATA);
> if (skipMetadataOnResponse != skipMetadataOnRequest) {
> logger.warn("Inconsistent skipMetadata on streamId
> {}, was {} in request but {} in response",
> request.getStreamId(),
> skipMetadataOnRequest,
> skipMetadataOnResponse);
> }
> }
> {code}
> We observed the warning with (false, true) during our tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8033) Filtering for CONTAINS on sets is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160154#comment-14160154
]
Benjamin Lerer commented on CASSANDRA-8033:
---
+1
> Filtering for CONTAINS on sets is broken
>
>
> Key: CASSANDRA-8033
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8033
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: ubuntu 14.04 lts, cassandra 2.1.0
>Reporter: Tuukka Mustonen
>Assignee: Tyler Hobbs
> Fix For: 2.1.1
>
> Attachments: 8033-2.1.txt
>
>
> With compound partition key, when you add index for one part and query by
> that AND with CONTAINS, the CONTAINS clause does nothing.
> Steps to reproduce:
> {code}
> -- drop existing data
> DROP TABLE IF EXISTS test;
> -- create data
> CREATE TABLE test (id1 int, id2 int, tag text, items set, PRIMARY KEY
> ((id1, id2), tag));
> INSERT INTO test (id1, id2, tag, items) VALUES (1, 1, 'cars', {'ford',
> 'toyota'});
> INSERT INTO test (id1, id2, tag, items) VALUES (1, 2, 'planes', {'airbus',
> 'boeing'});
> INSERT INTO test (id1, id2, tag, items) VALUES (2, 1, 'cars', {'bmw',
> 'ford'});
> -- if we create INDEX for items, query works ok
> CREATE INDEX test_items ON test(items);
> SELECT * FROM test WHERE items CONTAINS 'ford'; -- returns 2 rows
> -- even this works now (but won't work later)
> SELECT * FROM test WHERE id1 = 1 AND items CONTAINS 'ford' ALLOW FILTERING;
> -- returns 1 row
> -- let's create the index on id1 instead
> DROP INDEX test_items;
> CREATE INDEX test_id1s ON test(id1);
> -- these return all rows of id1 = 1 now, CONTAINS clause does nothing
> SELECT * FROM test WHERE id1 = 1 AND items CONTAINS 'ford' ALLOW FILTERING;
> -- should return 1 row but returns 2
> SELECT * FROM test WHERE id1 = 1 AND items CONTAINS 'doesnotexist' ALLOW
> FILTERING; -- should return 0 rows but returns 2
> -- add index back
> CREATE INDEX test_items ON test(items);
> -- no effect, same as before
> SELECT * FROM test WHERE id1 = 1 AND items CONTAINS 'ford' ALLOW FILTERING;
> -- should return 1 row but returns 2
> SELECT * FROM test WHERE id1 = 1 AND items CONTAINS 'doesnotexist' ALLOW
> FILTERING; -- should return 0 rows but returns 2
> {code}
> Sample output:
> {code}
> cqlsh:stable> -- drop existing data
> cqlsh:stable> DROP TABLE IF EXISTS test;
> cqlsh:stable>
> cqlsh:stable> -- create data
> cqlsh:stable> CREATE TABLE test (id1 int, id2 int, tag text, items set,
> PRIMARY KEY ((id1, id2), tag));
> cqlsh:stable> INSERT INTO test (id1, id2, tag, items) VALUES (1, 1, 'cars',
> {'ford', 'toyota'});
> cqlsh:stable> INSERT INTO test (id1, id2, tag, items) VALUES (1, 2, 'planes',
> {'airbus', 'boeing'});
> cqlsh:stable> INSERT INTO test (id1, id2, tag, items) VALUES (2, 1, 'cars',
> {'bmw', 'ford'});
> cqlsh:stable>
> cqlsh:stable> -- if we create INDEX for items, query works ok
> cqlsh:stable> CREATE INDEX test_items ON test(items);
> cqlsh:stable> SELECT * FROM test WHERE items CONTAINS 'ford'; -- returns 2
> rows
> id1 | id2 | tag | items
> -+-+--+
>2 | 1 | cars |{'bmw', 'ford'}
>1 | 1 | cars | {'ford', 'toyota'}
> (2 rows)
> cqlsh:stable>
> cqlsh:stable> -- even this works now (but won't work later)
> cqlsh:stable> SELECT * FROM test WHERE id1 = 1 AND items CONTAINS 'ford'
> ALLOW FILTERING; -- returns 1 row
> id1 | id2 | tag | items
> -+-+--+
>1 | 1 | cars | {'ford', 'toyota'}
> (1 rows)
> cqlsh:stable>
> cqlsh:stable> -- let's create the index on id1 instead
> cqlsh:stable> DROP INDEX test_items;
> cqlsh:stable> CREATE INDEX test_id1s ON test(id1);
> cqlsh:stable>
> cqlsh:stable> -- these return all rows of id1 = 1 now, CONTAINS clause does
> nothing
> cqlsh:stable> SELECT * FROM test WHERE id1 = 1 AND items CONTAINS 'ford'
> ALLOW FILTERING; -- should return 1 row but returns 2
> id1 | id2 | tag| items
> -+-++--
>1 | 2 | planes | {'airbus', 'boeing'}
>1 | 1 | cars | {'ford', 'toyota'}
> (2 rows)
> cqlsh:stable> SELECT * FROM test WHERE id1 = 1 AND items CONTAINS
> 'doesnotexist' ALLOW FILTERING; -- should return 0 rows but returns 2
> id1 | id2 | tag| items
> -+-++--
>1 | 2 | planes | {'airbus', 'boeing'}
>1 | 1 | cars | {'ford', 'toyota'}
> (2 rows)
> cqlsh:stable>
> cqlsh:stable> -- add index back
> cqlsh:stable> CREATE INDEX test_items ON test(items);
> cqlsh:stable>
> cqlsh:stable> -- no effect, same as before
> cqlsh:stable> SELECT * FROM test WHERE id1 = 1 AND items CONTAINS 'ford'
> ALLOW FILTERING; -- should return 1 row but returns 2
> id1 | id2 | tag| items
> -+-++--
>
[2/2] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/68371c65 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/68371c65 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/68371c65 Branch: refs/heads/trunk Commit: 68371c655c4a6f4590c3fd9200a0042009ca7e5a Parents: 50c5da9 6c3a3e1 Author: Marcus Eriksson Authored: Mon Oct 6 12:44:48 2014 +0200 Committer: Marcus Eriksson Committed: Mon Oct 6 12:44:48 2014 +0200 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/db/DataTracker.java | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/68371c65/CHANGES.txt -- diff --cc CHANGES.txt index dc9a32f,7cce86e..8ecafd5 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,34 -1,5 +1,35 @@@ +3.0 + * Improve query to read paxos table on propose (CASSANDRA-7929) + * Remove cassandra-cli (CASSANDRA-7920) + * Optimize java source-based UDF invocation (CASSANDRA-7924) + * Accept dollar quoted strings in CQL (CASSANDRA-7769) + * Make assassinate a first class command (CASSANDRA-7935) + * Support IN clause on any clustering column (CASSANDRA-4762) + * Improve compaction logging (CASSANDRA-7818) + * Remove YamlFileNetworkTopologySnitch (CASSANDRA-7917) + * Support Java source code for user-defined functions (CASSANDRA-7562) + * Require arg types to disambiguate UDF drops (CASSANDRA-7812) + * Do anticompaction in groups (CASSANDRA-6851) + * Verify that UDF class methods are static (CASSANDRA-7781) + * Support pure user-defined functions (CASSANDRA-7395, 7740) + * Permit configurable timestamps with cassandra-stress (CASSANDRA-7416) + * Move sstable RandomAccessReader to nio2, which allows using the + FILE_SHARE_DELETE flag on Windows (CASSANDRA-4050) + * Remove CQL2 (CASSANDRA-5918) + * Add Thrift get_multi_slice call (CASSANDRA-6757) + * Optimize fetching multiple cells by name (CASSANDRA-6933) + * Allow compilation in java 8 (CASSANDRA-7028) + * Make incremental repair default (CASSANDRA-7250) + * Enable code coverage thru JaCoCo (CASSANDRA-7226) + * Switch external naming of 'column families' to 'tables' (CASSANDRA-4369) + * Shorten SSTable path (CASSANDRA-6962) + * Use unsafe mutations for most unit tests (CASSANDRA-6969) + * Fix race condition during calculation of pending ranges (CASSANDRA-7390) + * Fail on very large batch sizes (CASSANDRA-8011) + + 2.1.1 + * Properly track added size (CASSANDRA-7239) * Allow compilation in java 8 (CASSANDRA-7208) * Fix Assertion error on RangeTombstoneList diff (CASSANDRA-8013) * Release references to overlapping sstables during compaction (CASSANDRA-7819)
git commit: Track added size correctly
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 aca80da38 -> 6c3a3e130
Track added size correctly
Patch by marcuse; reviewed by jbellis for CASSANDRA-7239
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6c3a3e13
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6c3a3e13
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6c3a3e13
Branch: refs/heads/cassandra-2.1
Commit: 6c3a3e130130e2823ba71ecd8a0e2680de23efd5
Parents: aca80da
Author: Marcus Eriksson
Authored: Fri Oct 3 11:05:54 2014 +0200
Committer: Marcus Eriksson
Committed: Mon Oct 6 12:43:19 2014 +0200
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/db/DataTracker.java | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3a3e13/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index beab957..7cce86e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.1
+ * Properly track added size (CASSANDRA-7239)
* Allow compilation in java 8 (CASSANDRA-7208)
* Fix Assertion error on RangeTombstoneList diff (CASSANDRA-8013)
* Release references to overlapping sstables during compaction
(CASSANDRA-7819)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3a3e13/src/java/org/apache/cassandra/db/DataTracker.java
--
diff --git a/src/java/org/apache/cassandra/db/DataTracker.java
b/src/java/org/apache/cassandra/db/DataTracker.java
index 8d66e2a..f09c725 100644
--- a/src/java/org/apache/cassandra/db/DataTracker.java
+++ b/src/java/org/apache/cassandra/db/DataTracker.java
@@ -264,7 +264,7 @@ public class DataTracker
{
replace(sstables, Collections.emptyList());
notifySSTablesChanged(sstables, allReplacements, compactionType);
-for (SSTableReader sstable : sstables)
+for (SSTableReader sstable : allReplacements)
{
long bytesOnDisk = sstable.bytesOnDisk();
cfstore.metric.totalDiskSpaceUsed.inc(bytesOnDisk);
[1/2] git commit: Track added size correctly
Repository: cassandra
Updated Branches:
refs/heads/trunk 50c5da991 -> 68371c655
Track added size correctly
Patch by marcuse; reviewed by jbellis for CASSANDRA-7239
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6c3a3e13
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6c3a3e13
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6c3a3e13
Branch: refs/heads/trunk
Commit: 6c3a3e130130e2823ba71ecd8a0e2680de23efd5
Parents: aca80da
Author: Marcus Eriksson
Authored: Fri Oct 3 11:05:54 2014 +0200
Committer: Marcus Eriksson
Committed: Mon Oct 6 12:43:19 2014 +0200
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/db/DataTracker.java | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3a3e13/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index beab957..7cce86e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.1
+ * Properly track added size (CASSANDRA-7239)
* Allow compilation in java 8 (CASSANDRA-7208)
* Fix Assertion error on RangeTombstoneList diff (CASSANDRA-8013)
* Release references to overlapping sstables during compaction
(CASSANDRA-7819)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3a3e13/src/java/org/apache/cassandra/db/DataTracker.java
--
diff --git a/src/java/org/apache/cassandra/db/DataTracker.java
b/src/java/org/apache/cassandra/db/DataTracker.java
index 8d66e2a..f09c725 100644
--- a/src/java/org/apache/cassandra/db/DataTracker.java
+++ b/src/java/org/apache/cassandra/db/DataTracker.java
@@ -264,7 +264,7 @@ public class DataTracker
{
replace(sstables, Collections.emptyList());
notifySSTablesChanged(sstables, allReplacements, compactionType);
-for (SSTableReader sstable : sstables)
+for (SSTableReader sstable : allReplacements)
{
long bytesOnDisk = sstable.bytesOnDisk();
cfstore.metric.totalDiskSpaceUsed.inc(bytesOnDisk);
[jira] [Resolved] (CASSANDRA-8042) Inconsistent static column behavior after row deletion
[
https://issues.apache.org/jira/browse/CASSANDRA-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-8042.
-
Resolution: Not a Problem
bq. but such behavior looks (just looks) inconsistent
I'm not sure I agree. If you do
{noformat}
INSERT INTO tt (c1, c2, c3, cs) VALUES ( '1', '1-3', 'x', 's3') USING TTL 20;
{noformat}
you're explicitely mentioning your static column {{cs}}, so it makes sense imo
that the TTL is applied to it. If you do
{noformat}
DELETE FROM tt1 WHERE c1='1' AND c2 = '1-2';
{noformat}
however, you're not explicitly listing any columns. If you were listing columns
explicitely, i.e. if you do:
{noformat}
DELETE c3, cs FROM tt1 WHERE c1='1' AND c2 = '1-2';
{noformat}
then it will delete {{cs}} and be consistent with the {{INSERT}} case.
Deleting a row without listing static columns explicitely does not delete the
static columns. Maybe that behavior is not completely intuitive (but it's more
useful that way in practice in most usage of static columns) but I wouldn't say
it brings inconsistencies with ttls per se.
In any case, it's working as designed so unless someone has a concrete
suggestion/rational for changing the design, I'm closing as "not a problem".
bq. is it possible to insert a row with TTL but not to define TTL for static
column without using batches?
It's not (but it's not like there is any downside to using batches in such case
so ...).
> Inconsistent static column behavior after row deletion
> --
>
> Key: CASSANDRA-8042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8042
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: viasyn
> Fix For: 2.1.1
>
>
> I've a table with static column defined. I'm inserting some rows with TTL
> defined, then one of row expires TTL of all the rows with same PK turns into
> null:
> {code}
> cqlsh:test> create table tt ( c1 text , c2 text , c3 text, cs text static,
> PRIMARY KEY (c1, c2) );
> cqlsh:test> insert into tt (c1, c2, c3, cs) VALUES ( '1', '1-1', 'x', 's1')
> USING TTL 10;
> cqlsh:test> insert into tt (c1, c2, c3, cs) VALUES ( '1', '1-2', 'x', 's2')
> USING TTL 5;
> cqlsh:test> insert into tt (c1, c2, c3, cs) VALUES ( '1', '1-3', 'x', 's3')
> USING TTL 20;
> cqlsh:test> insert into tt (c1, c2, c3, cs) VALUES ( '1', '1-4', 'x', 's4')
> USING TTL 3;
> cqlsh:test> select * from tt;
> c1 | c2 | cs | c3
> +-++
> 1 | 1-1 | s4 | x
> 1 | 1-2 | s4 | x
> 1 | 1-3 | s4 | x
> 1 | 1-4 | s4 | x
> (4 rows)
> cqlsh:test> select * from tt;
> c1 | c2 | cs | c3
> +-++
> 1 | 1-1 | s4 | x
> 1 | 1-2 | s4 | x
> 1 | 1-3 | s4 | x
> 1 | 1-4 | s4 | x
> (4 rows)
> cqlsh:test> select * from tt;
> c1 | c2 | cs | c3
> +-+--+
> 1 | 1-1 | null | x
> 1 | 1-2 | null | x
> 1 | 1-3 | null | x
> (3 rows)
> {code}
> Same scenario with manual DELETion leads to another result:
> {code}
> cqlsh:test> create table tt1 ( c1 text , c2 text , c3 text, cs text static,
> PRIMARY KEY (c1, c2) );
> cqlsh:test> insert into tt1 (c1, c2, c3, cs) VALUES ( '1', '1-1', 'x', 's1');
> cqlsh:test> insert into tt1 (c1, c2, c3, cs) VALUES ( '1', '1-2', 'x', 's2');
> cqlsh:test> insert into tt1 (c1, c2, c3, cs) VALUES ( '1', '1-3', 'x', 's3');
> cqlsh:test> insert into tt1 (c1, c2, c3, cs) VALUES ( '1', '1-4', 'x', 's4');
> cqlsh:test> select * from tt1;
> c1 | c2 | cs | c3
> +-++
> 1 | 1-1 | s4 | x
> 1 | 1-2 | s4 | x
> 1 | 1-3 | s4 | x
> 1 | 1-4 | s4 | x
> (4 rows)
> cqlsh:test> delete from tt1 WHERE c1='1' AND c2 = '1-2';
> cqlsh:test> select * from tt1;
> c1 | c2 | cs | c3
> +-++
> 1 | 1-1 | s4 | x
> 1 | 1-3 | s4 | x
> 1 | 1-4 | s4 | x
> (3 rows)
> cqlsh:test> delete from tt1 WHERE c1='1' AND c2 = '1-4';
> cqlsh:test> select * from tt1;
> c1 | c2 | cs | c3
> +-++
> 1 | 1-1 | s4 | x
> 1 | 1-3 | s4 | x
> (2 rows)
> {code}
> Is this behavior bug or it's declared somewhere? Is it really good that
> deletion behavior is inconsistent?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4914) Aggregation functions in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160217#comment-14160217
]
Sylvain Lebresne commented on CASSANDRA-4914:
-
The last patch looks almost good to go (provided it's rebased) for me but there
seems to be some confusion around the {{reset}} method for {{Selection}}.
You've removed the abstract one in {{Selection}} itself, but both
{{SimpleSelection}} and {{SelectionWithFunctions}} still have a {{reset}}
method which, as far as I can tell, is never called. And while the one in
{{SimpleSelection}} does nothing, the one in {{SelectionWithFunctions}} seems
to do something. I think what you'd want is add back the {{reset}} method to
{{Selection}} but actually call it in {{ResultSetBuilder.newRow/build}} (as a
nit, you can then move the {{current = null}} in {{SimpleSelection}} in the
{{reset}} method for consistency).
bq. Postgres's approach to user-defined aggregation functions is almost
exactly this: http://www.postgresql.org/docs/8.3/static/sql-createaggregate.html
I agree that it's where we want to go (there was some discussion around this at
the bootcamp that ended up with the same conclusion but it sound like I forgot
to update JIRA with said conclusions). That said, this ticket is mostly about
the internal interface for aggregation functions and as far as I can tell,
nothing in the attached patch limit us from going with a "reduce-style"
approach for UDF (it will be in fact rather simple). So let's maybe leave the
discussion on UDF in CASSANDRA-8053.
> Aggregation functions in CQL
>
>
> Key: CASSANDRA-4914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4914
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Vijay
>Assignee: Benjamin Lerer
> Labels: cql, docs
> Fix For: 3.0
>
> Attachments: CASSANDRA-4914-V2.txt, CASSANDRA-4914-V3.txt,
> CASSANDRA-4914-V4.txt, CASSANDRA-4914.txt
>
>
> The requirement is to do aggregation of data in Cassandra (Wide row of column
> values of int, double, float etc).
> With some basic agree gate functions like AVG, SUM, Mean, Min, Max, etc (for
> the columns within a row).
> Example:
> SELECT * FROM emp WHERE empID IN (130) ORDER BY deptID DESC;
>
> empid | deptid | first_name | last_name | salary
> ---+++---+
>130 | 3 | joe| doe | 10.1
>130 | 2 | joe| doe |100
>130 | 1 | joe| doe | 1e+03
>
> SELECT sum(salary), empid FROM emp WHERE empID IN (130);
>
> sum(salary) | empid
> -+
>1110.1| 130
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8053) Support for user defined aggregate functions
[
https://issues.apache.org/jira/browse/CASSANDRA-8053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160225#comment-14160225
]
Sylvain Lebresne commented on CASSANDRA-8053:
-
As discussed in CASSANDRA-4914 (and with a few others), we should go with the
same approach than prostgres, that is what described at
http://www.postgresql.org/docs/8.3/static/sql-createaggregate.html. In fact,
reading that document, I don't seen a good for not going for exactly the same
syntax and behavior (minus a couple stuff that we don't need to support, at
least not initially, like the {{SORTOP}}). An aggregate would thus just be
built from existing "scalar" functions and there is no specific questions about
"UDF" flavors to consider.
> Support for user defined aggregate functions
>
>
> Key: CASSANDRA-8053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8053
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Robert Stupp
> Labels: cql, udf
> Fix For: 3.0
>
>
> CASSANDRA-4914 introduces aggregate functions.
> This ticket is about to decide how we can support "user defined aggregate
> functions". UD aggregate functions should be supported for all UDF flavors
> (class, java, jsr223).
> Things to consider:
> * Special implementations for each scripting language should be omitted
> * No exposure of internal APIs (e.g. {{AggregateFunction}} interface)
> * No need for users to deal with serializers / codecs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8053) Support for user defined aggregate functions
[
https://issues.apache.org/jira/browse/CASSANDRA-8053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-8053:
-
Assignee: Benjamin Lerer
> Support for user defined aggregate functions
>
>
> Key: CASSANDRA-8053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8053
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Robert Stupp
>Assignee: Benjamin Lerer
> Labels: cql, udf
> Fix For: 3.0
>
>
> CASSANDRA-4914 introduces aggregate functions.
> This ticket is about to decide how we can support "user defined aggregate
> functions". UD aggregate functions should be supported for all UDF flavors
> (class, java, jsr223).
> Things to consider:
> * Special implementations for each scripting language should be omitted
> * No exposure of internal APIs (e.g. {{AggregateFunction}} interface)
> * No need for users to deal with serializers / codecs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8063) Consider removing UDF-as-class functionality
Sylvain Lebresne created CASSANDRA-8063:
---
Summary: Consider removing UDF-as-class functionality
Key: CASSANDRA-8063
URL: https://issues.apache.org/jira/browse/CASSANDRA-8063
Project: Cassandra
Issue Type: Bug
Reporter: Sylvain Lebresne
Fix For: 3.0
We've introduce 2 ways to provide (scalar) UDFs: either by providing a
class+method name (and assuming C* can find such class and method in the
classpath), or by providing the body of the function directly in the {{CREATE
FUNCTION}} statement (with such body being able to be in either java or some
variety of scripting languages).
I submit that we remove the first option: the declaration of functions from a
class+method name. I was the first to insist on adding it, but in hindsight I
think it adds more complexity/confusion than anything else. More specifically,
I think the UDF-as-class option is always inferior to CASSANDRA-7562 because:
# it's more error prone. You have to manually deploy the class containing the
function to every C* node (and make sure it is in the classpath). It's way too
easy to end up with some node not having the function due to simple operator
error.
# it's not faster. In fact, post-CASSANDRA-7924, the UDF-as-java-source is
probably faster since it doesn't involve reflection while the UDF-as-class
option does.
Overall, I think removing the UDF-as-class will simplify things without really
losing anything (of course, we can re-evaluate this in the future if new
arguments arises, but it's easier to add than to remove).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8063) Consider removing UDF-as-class functionality
[
https://issues.apache.org/jira/browse/CASSANDRA-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-8063:
Labels: cql (was: )
> Consider removing UDF-as-class functionality
>
>
> Key: CASSANDRA-8063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8063
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
> Labels: cql
> Fix For: 3.0
>
>
> We've introduce 2 ways to provide (scalar) UDFs: either by providing a
> class+method name (and assuming C* can find such class and method in the
> classpath), or by providing the body of the function directly in the {{CREATE
> FUNCTION}} statement (with such body being able to be in either java or some
> variety of scripting languages).
> I submit that we remove the first option: the declaration of functions from a
> class+method name. I was the first to insist on adding it, but in hindsight I
> think it adds more complexity/confusion than anything else. More
> specifically, I think the UDF-as-class option is always inferior to
> CASSANDRA-7562 because:
> # it's more error prone. You have to manually deploy the class containing the
> function to every C* node (and make sure it is in the classpath). It's way
> too easy to end up with some node not having the function due to simple
> operator error.
> # it's not faster. In fact, post-CASSANDRA-7924, the UDF-as-java-source is
> probably faster since it doesn't involve reflection while the UDF-as-class
> option does.
> Overall, I think removing the UDF-as-class will simplify things without
> really losing anything (of course, we can re-evaluate this in the future if
> new arguments arises, but it's easier to add than to remove).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8063) Consider removing UDF-as-class functionality
[
https://issues.apache.org/jira/browse/CASSANDRA-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160244#comment-14160244
]
Robert Stupp commented on CASSANDRA-8063:
-
+1 for removing "class" UDFs due to the facts Sylvain mentions
> Consider removing UDF-as-class functionality
>
>
> Key: CASSANDRA-8063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8063
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
> Labels: cql
> Fix For: 3.0
>
>
> We've introduce 2 ways to provide (scalar) UDFs: either by providing a
> class+method name (and assuming C* can find such class and method in the
> classpath), or by providing the body of the function directly in the {{CREATE
> FUNCTION}} statement (with such body being able to be in either java or some
> variety of scripting languages).
> I submit that we remove the first option: the declaration of functions from a
> class+method name. I was the first to insist on adding it, but in hindsight I
> think it adds more complexity/confusion than anything else. More
> specifically, I think the UDF-as-class option is always inferior to
> CASSANDRA-7562 because:
> # it's more error prone. You have to manually deploy the class containing the
> function to every C* node (and make sure it is in the classpath). It's way
> too easy to end up with some node not having the function due to simple
> operator error.
> # it's not faster. In fact, post-CASSANDRA-7924, the UDF-as-java-source is
> probably faster since it doesn't involve reflection while the UDF-as-class
> option does.
> Overall, I think removing the UDF-as-class will simplify things without
> really losing anything (of course, we can re-evaluate this in the future if
> new arguments arises, but it's easier to add than to remove).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-4914) Aggregation functions in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-4914:
--
Attachment: CASSANDRA-4914-V5.txt
This patch differs from the previous by the following points:
# The patch has been rebased against the latest trunk
# {{Selection.reset()}}, {{Selection.ResultSetBuilder}} and {{SimpleSelection}}
have been modified as suggested.
> Aggregation functions in CQL
>
>
> Key: CASSANDRA-4914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4914
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Vijay
>Assignee: Benjamin Lerer
> Labels: cql, docs
> Fix For: 3.0
>
> Attachments: CASSANDRA-4914-V2.txt, CASSANDRA-4914-V3.txt,
> CASSANDRA-4914-V4.txt, CASSANDRA-4914-V5.txt, CASSANDRA-4914.txt
>
>
> The requirement is to do aggregation of data in Cassandra (Wide row of column
> values of int, double, float etc).
> With some basic agree gate functions like AVG, SUM, Mean, Min, Max, etc (for
> the columns within a row).
> Example:
> SELECT * FROM emp WHERE empID IN (130) ORDER BY deptID DESC;
>
> empid | deptid | first_name | last_name | salary
> ---+++---+
>130 | 3 | joe| doe | 10.1
>130 | 2 | joe| doe |100
>130 | 1 | joe| doe | 1e+03
>
> SELECT sum(salary), empid FROM emp WHERE empID IN (130);
>
> sum(salary) | empid
> -+
>1110.1| 130
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7272) Add "Major" Compaction to LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160270#comment-14160270 ] T Jake Luciani commented on CASSANDRA-7272: --- We still need a way to remove the potential duplicate partitions from many repairs as described in the summary. > Add "Major" Compaction to LCS > -- > > Key: CASSANDRA-7272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7272 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: T Jake Luciani >Priority: Minor > Labels: compaction > Fix For: 3.0 > > > LCS has a number of minor issues (maybe major depending on your perspective). > LCS is primarily used for wide rows so for instance when you repair data in > LCS you end up with a copy of an entire repaired row in L0. Over time if you > repair you end up with multiple copies of a row in L0 - L5. This can make > predicting disk usage confusing. > Another issue is cleaning up tombstoned data. If a tombstone lives in level > 1 and data for the cell lives in level 5 the data will not be reclaimed from > disk until the tombstone reaches level 5. > I propose we add a "major" compaction for LCS that forces consolidation of > data to level 5 to address these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7272) Add "Major" Compaction to LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160272#comment-14160272 ] Marcus Eriksson commented on CASSANDRA-7272: bq. We still need a way to remove the potential duplicate partitions It does that, perhaps that (CASSANDRA-7019) patch should go into this ticket instead > Add "Major" Compaction to LCS > -- > > Key: CASSANDRA-7272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7272 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: T Jake Luciani >Priority: Minor > Labels: compaction > Fix For: 3.0 > > > LCS has a number of minor issues (maybe major depending on your perspective). > LCS is primarily used for wide rows so for instance when you repair data in > LCS you end up with a copy of an entire repaired row in L0. Over time if you > repair you end up with multiple copies of a row in L0 - L5. This can make > predicting disk usage confusing. > Another issue is cleaning up tombstoned data. If a tombstone lives in level > 1 and data for the cell lives in level 5 the data will not be reclaimed from > disk until the tombstone reaches level 5. > I propose we add a "major" compaction for LCS that forces consolidation of > data to level 5 to address these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-7272) Add "Major" Compaction to LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani resolved CASSANDRA-7272. --- Resolution: Duplicate Let's just update the title of the other ticket then > Add "Major" Compaction to LCS > -- > > Key: CASSANDRA-7272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7272 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: T Jake Luciani >Priority: Minor > Labels: compaction > Fix For: 3.0 > > > LCS has a number of minor issues (maybe major depending on your perspective). > LCS is primarily used for wide rows so for instance when you repair data in > LCS you end up with a copy of an entire repaired row in L0. Over time if you > repair you end up with multiple copies of a row in L0 - L5. This can make > predicting disk usage confusing. > Another issue is cleaning up tombstoned data. If a tombstone lives in level > 1 and data for the cell lives in level 5 the data will not be reclaimed from > disk until the tombstone reaches level 5. > I propose we add a "major" compaction for LCS that forces consolidation of > data to level 5 to address these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
git commit: Fix more stress bugs (ninja)
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 6c3a3e130 -> a8052d7c8
Fix more stress bugs (ninja)
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a8052d7c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a8052d7c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a8052d7c
Branch: refs/heads/cassandra-2.1
Commit: a8052d7c812fd232d7a249aa5a72afdeaa9f4583
Parents: 6c3a3e1
Author: Jake Luciani
Authored: Mon Oct 6 10:36:41 2014 -0400
Committer: Jake Luciani
Committed: Mon Oct 6 10:36:41 2014 -0400
--
.../org/apache/cassandra/stress/generate/Partition.java | 7 +--
.../stress/operations/userdefined/SchemaInsert.java | 11 +--
2 files changed, 14 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a8052d7c/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
--
diff --git
a/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
b/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
index 18f5732..66f8c1d 100644
--- a/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
+++ b/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
@@ -271,10 +271,13 @@ public class Partition
tosort.add((Comparable) generator.generate());
Collections.sort(tosort);
for (int i = 0 ; i < count ; i++)
-if (i == 0 || tosort.get(i - 1).compareTo(i) < 0)
-queue.add(tosort.get(i));
+queue.add(tosort.get(i));
break;
}
+else
+{
+throw new RuntimeException("Generator class is not
comparable: "+generator.clazz);
+}
case ARBITRARY:
unique.clear();
for (int i = 0 ; i < count ; i++)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a8052d7c/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
--
diff --git
a/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
b/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
index ffa965f..8e20ab3 100644
---
a/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
+++
b/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
@@ -84,7 +84,7 @@ public class SchemaInsert extends SchemaStatement
// 65535 is max number of stmts per batch, so if we have more, we
need to manually batch them
for (int j = 0 ; j < stmts.size() ; j += 65535)
{
-List substmts = stmts.subList(j,
Math.min(stmts.size(), j + 65535));
+List substmts = stmts.subList(j, Math.min(j +
stmts.size(), j + 65535));
Statement stmt;
if (stmts.size() == 1)
{
@@ -98,7 +98,14 @@ public class SchemaInsert extends SchemaStatement
stmt = batch;
}
-validate(client.getSession().execute(stmt));
+try
+{
+validate(client.getSession().execute(stmt));
+}
+catch (ClassCastException e)
+{
+e.printStackTrace();
+}
}
for (Partition.RowIterator iterator : iterators)
[1/2] git commit: Fix more stress bugs (ninja)
Repository: cassandra
Updated Branches:
refs/heads/trunk 68371c655 -> bc246e132
Fix more stress bugs (ninja)
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a8052d7c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a8052d7c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a8052d7c
Branch: refs/heads/trunk
Commit: a8052d7c812fd232d7a249aa5a72afdeaa9f4583
Parents: 6c3a3e1
Author: Jake Luciani
Authored: Mon Oct 6 10:36:41 2014 -0400
Committer: Jake Luciani
Committed: Mon Oct 6 10:36:41 2014 -0400
--
.../org/apache/cassandra/stress/generate/Partition.java | 7 +--
.../stress/operations/userdefined/SchemaInsert.java | 11 +--
2 files changed, 14 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a8052d7c/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
--
diff --git
a/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
b/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
index 18f5732..66f8c1d 100644
--- a/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
+++ b/tools/stress/src/org/apache/cassandra/stress/generate/Partition.java
@@ -271,10 +271,13 @@ public class Partition
tosort.add((Comparable) generator.generate());
Collections.sort(tosort);
for (int i = 0 ; i < count ; i++)
-if (i == 0 || tosort.get(i - 1).compareTo(i) < 0)
-queue.add(tosort.get(i));
+queue.add(tosort.get(i));
break;
}
+else
+{
+throw new RuntimeException("Generator class is not
comparable: "+generator.clazz);
+}
case ARBITRARY:
unique.clear();
for (int i = 0 ; i < count ; i++)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a8052d7c/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
--
diff --git
a/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
b/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
index ffa965f..8e20ab3 100644
---
a/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
+++
b/tools/stress/src/org/apache/cassandra/stress/operations/userdefined/SchemaInsert.java
@@ -84,7 +84,7 @@ public class SchemaInsert extends SchemaStatement
// 65535 is max number of stmts per batch, so if we have more, we
need to manually batch them
for (int j = 0 ; j < stmts.size() ; j += 65535)
{
-List substmts = stmts.subList(j,
Math.min(stmts.size(), j + 65535));
+List substmts = stmts.subList(j, Math.min(j +
stmts.size(), j + 65535));
Statement stmt;
if (stmts.size() == 1)
{
@@ -98,7 +98,14 @@ public class SchemaInsert extends SchemaStatement
stmt = batch;
}
-validate(client.getSession().execute(stmt));
+try
+{
+validate(client.getSession().execute(stmt));
+}
+catch (ClassCastException e)
+{
+e.printStackTrace();
+}
}
for (Partition.RowIterator iterator : iterators)
[2/2] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bc246e13 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bc246e13 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bc246e13 Branch: refs/heads/trunk Commit: bc246e13261dff243e4d1d0dd4e954200b1a9330 Parents: 68371c6 a8052d7 Author: Jake Luciani Authored: Mon Oct 6 10:38:03 2014 -0400 Committer: Jake Luciani Committed: Mon Oct 6 10:38:03 2014 -0400 -- .../org/apache/cassandra/stress/generate/Partition.java | 7 +-- .../stress/operations/userdefined/SchemaInsert.java | 11 +-- 2 files changed, 14 insertions(+), 4 deletions(-) --
[jira] [Updated] (CASSANDRA-7761) Upgrade netty
[ https://issues.apache.org/jira/browse/CASSANDRA-7761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7761: -- Fix Version/s: (was: 2.1.1) 3.0 > Upgrade netty > - > > Key: CASSANDRA-7761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7761 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Assignee: T Jake Luciani >Priority: Minor > Fix For: 3.0 > > > Latest netty contains the proper fix for CASSANDRA-7695 plus some of the > performance patches [~benedict] contributed. We should upgrade to this > following extensive burn in testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6506) counters++ split counter context shards into separate cells
[ https://issues.apache.org/jira/browse/CASSANDRA-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-6506: - Fix Version/s: (was: 3.0) 3.1 > counters++ split counter context shards into separate cells > --- > > Key: CASSANDRA-6506 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6506 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Fix For: 3.1 > > > This change is related to, but somewhat orthogonal to CASSANDRA-6504. > Currently all the shard tuples for a given counter cell are packed, in sorted > order, in one binary blob. Thus reconciling N counter cells requires > allocating a new byte buffer capable of holding the union of the two > context's shards N-1 times. > For writes, in post CASSANDRA-6504 world, it also means reading more data > than we have to (the complete context, when all we need is the local node's > global shard). > Splitting the context into separate cells, one cell per shard, will help to > improve this. We did a similar thing with super columns for CASSANDRA-3237. > Incidentally, doing this split is now possible thanks to CASSANDRA-3237. > Doing this would also simplify counter reconciliation logic. Getting rid of > old contexts altogether can be done trivially with upgradesstables. > In fact, we should be able to put the logical clock into the cell's > timestamp, and use regular Cell-s and regular Cell reconcile() logic for the > shards, especially once we get rid of the local/remote shards some time in > the future (until then we still have to differentiate between > global/remote/local shards and their priority rules). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7393) Replace counter cache with optimised counter read path
[ https://issues.apache.org/jira/browse/CASSANDRA-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-7393: - Fix Version/s: (was: 3.0) 3.1 > Replace counter cache with optimised counter read path > -- > > Key: CASSANDRA-7393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7393 > Project: Cassandra > Issue Type: Sub-task >Reporter: Aleksey Yeschenko > Fix For: 3.1 > > > As mentioned in CASSANDRA-7366, we can utilize the optimizations in > CollationController#collectTimeOrderedData() now for the read-before-write > counter path, and get most/all of the benefits of the counter cache for > 'free' + get better 'cold' read performance as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
[
https://issues.apache.org/jira/browse/CASSANDRA-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160438#comment-14160438
]
Philip Thompson commented on CASSANDRA-8019:
This appears to be affecting 2.0-HEAD as well.
> Windows Unit tests and Dtests erroring due to sstable deleting task error
> -
>
> Key: CASSANDRA-8019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Labels: windows
> Fix For: 2.1.1
>
> Attachments: 8019_aggressive_v1.txt, 8019_conservative_v1.txt
>
>
> Currently a large number of dtests and unit tests are erroring on windows
> with the following error in the node log:
> {code}
> ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383
> SSTableDeletingTask.java:89 - Unable to delete
> c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
> (it will be removed on server restart; we'll also retry after GC)\n
> {code}
> git bisect points to the following commit:
> {code}
> 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
> commit 0e831007760bffced8687f51b99525b650d7e193
> Author: Benedict Elliott Smith
> Date: Fri Sep 19 18:17:19 2014 +0100
> Fix resource leak in event of corrupt sstable
> patch by benedict; review by yukim for CASSANDRA-7932
> :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
> f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
> :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
> 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
> :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
> de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
> {code}
> You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
[
https://issues.apache.org/jira/browse/CASSANDRA-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-8019:
---
Reproduced In: 2.0.11, 2.1.1 (was: 2.1.1)
> Windows Unit tests and Dtests erroring due to sstable deleting task error
> -
>
> Key: CASSANDRA-8019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Labels: windows
> Fix For: 2.1.1
>
> Attachments: 8019_aggressive_v1.txt, 8019_conservative_v1.txt
>
>
> Currently a large number of dtests and unit tests are erroring on windows
> with the following error in the node log:
> {code}
> ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383
> SSTableDeletingTask.java:89 - Unable to delete
> c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
> (it will be removed on server restart; we'll also retry after GC)\n
> {code}
> git bisect points to the following commit:
> {code}
> 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
> commit 0e831007760bffced8687f51b99525b650d7e193
> Author: Benedict Elliott Smith
> Date: Fri Sep 19 18:17:19 2014 +0100
> Fix resource leak in event of corrupt sstable
> patch by benedict; review by yukim for CASSANDRA-7932
> :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
> f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
> :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
> 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
> :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
> de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
> {code}
> You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7316) Windows: address potential JVM swapping
[ https://issues.apache.org/jira/browse/CASSANDRA-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160506#comment-14160506 ] Joshua McKenzie commented on CASSANDRA-7316: Updated branch [here|https://github.com/josh-mckenzie/cassandra/compare/pageFileUsage]. Added check for automatically configured page file usage as well since it wasn't returning from the other check, and suppressed convenience printing of size of page files if we got 0 back. Since I can't reproduce the 0 page file size problem [~philipthompson], please let me know how that part of it goes. The MaximumSize is [supposed to come back as a uint32|http://msdn.microsoft.com/en-us/library/aa394245(v=vs.85).aspx] so the current code *should* work with that. > Windows: address potential JVM swapping > --- > > Key: CASSANDRA-7316 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7316 > Project: Cassandra > Issue Type: Improvement >Reporter: Joshua McKenzie >Assignee: Joshua McKenzie >Priority: Minor > Labels: Windows, perfomance > Fix For: 2.1.1, 3.0 > > Attachments: 7316_v1.txt, 7316_v2.txt > > > Similar to mlockall() in CLibrary.java for linux, it would be nice to lock > the virtual address space on Windows to prevent page faults. > One option: Reference API: > http://msdn.microsoft.com/en-us/library/windows/desktop/aa366895(v=vs.85).aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7899) SSL does not work in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-7899: --- Attachment: 7899-v2.txt With the patch applied as is, compilation is broken as o.a.c.thrift.SSLTransportFactory imports one of the deleted classes [~jasobrown] can you take a look at v2 please? > SSL does not work in cassandra-cli > -- > > Key: CASSANDRA-7899 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7899 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Linux 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 > 21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > java version "1.7.0_17" > Java(TM) SE Runtime Environment (build 1.7.0_17-b02) > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) > [cqlsh 4.1.1 | Cassandra 2.0.10 | CQL spec 3.1.1 | Thrift protocol 19.39.0] >Reporter: Zdenek Ott >Assignee: Jason Brown > Attachments: 7899-v1.txt, 7899-v2.txt > > > When specify transport factory parameter '-tf > org.apache.cassandra.cli.transport.SSLTransportFactory' it throws exception, > see below, because SSLTransportFactory extends TTransportFactory not > ITransportFactory. > Exception in thread "main" java.lang.IllegalArgumentException: Cannot create > a transport factory 'org.apache.cassandra.cli.transport.SSLTransportFactory'. > at > org.apache.cassandra.cli.CliOptions.validateAndSetTransportFactory(CliOptions.java:288) > at > org.apache.cassandra.cli.CliOptions.processArgs(CliOptions.java:223) > at org.apache.cassandra.cli.CliMain.main(CliMain.java:230) > Caused by: java.lang.IllegalArgumentException: transport factory > 'org.apache.cassandra.cli.transport.SSLTransportFactory' not derived from > ITransportFactory > at > org.apache.cassandra.cli.CliOptions.validateAndSetTransportFactory(CliOptions.java:282) > ... 2 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8062) IllegalArgumentException passing blob as tuple value element in list
[
https://issues.apache.org/jira/browse/CASSANDRA-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8062:
---
Description:
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 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.buildMulti
[jira] [Commented] (CASSANDRA-7316) Windows: address potential JVM swapping
[
https://issues.apache.org/jira/browse/CASSANDRA-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160593#comment-14160593
]
Philip Thompson commented on CASSANDRA-7316:
+1. Reports: {code}WARNING! 1 swap file(s) detected
Name: d:\pagefile.sys{code} for me instead of printing out an incorrect
page size.
> Windows: address potential JVM swapping
> ---
>
> Key: CASSANDRA-7316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7316
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Joshua McKenzie
>Assignee: Joshua McKenzie
>Priority: Minor
> Labels: Windows, perfomance
> Fix For: 2.1.1, 3.0
>
> Attachments: 7316_v1.txt, 7316_v2.txt
>
>
> Similar to mlockall() in CLibrary.java for linux, it would be nice to lock
> the virtual address space on Windows to prevent page faults.
> One option: Reference API:
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366895(v=vs.85).aspx
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[4/6] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/af863d7d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/af863d7d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/af863d7d Branch: refs/heads/trunk Commit: af863d7d4f7f0fa89f8f607250f7f82d84572f4e Parents: a8052d7 6eec29e Author: Yuki Morishita Authored: Mon Oct 6 13:06:33 2014 -0500 Committer: Yuki Morishita Committed: Mon Oct 6 13:06:33 2014 -0500 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/tools/NodeProbe.java | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/af863d7d/CHANGES.txt -- diff --cc CHANGES.txt index 7cce86e,66d7e72..e9e9fce --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,63 -1,4 +1,64 @@@ -2.0.11: +2.1.1 + * Properly track added size (CASSANDRA-7239) + * Allow compilation in java 8 (CASSANDRA-7208) + * Fix Assertion error on RangeTombstoneList diff (CASSANDRA-8013) + * Release references to overlapping sstables during compaction (CASSANDRA-7819) + * Send notification when opening compaction results early (CASSANDRA-8034) + * Make native server start block until properly bound (CASSANDRA-7885) + * (cqlsh) Fix IPv6 support (CASSANDRA-7988) + * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939) + * Make sstablerepairedset take a list of files (CASSANDRA-7995) + * (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972) + * (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891) + * Fix resource leak in event of corrupt sstable + * (cqlsh) Add command line option for cqlshrc file path (CASSANDRA-7131) + * Provide visibility into prepared statements churn (CASSANDRA-7921, CASSANDRA-7930) + * Invalidate prepared statements when their keyspace or table is + dropped (CASSANDRA-7566) + * cassandra-stress: fix support for NetworkTopologyStrategy (CASSANDRA-7945) + * Fix saving caches when a table is dropped (CASSANDRA-7784) + * Add better error checking of new stress profile (CASSANDRA-7716) + * Use ThreadLocalRandom and remove FBUtilities.threadLocalRandom (CASSANDRA-7934) + * Prevent operator mistakes due to simultaneous bootstrap (CASSANDRA-7069) + * cassandra-stress supports whitelist mode for node config (CASSANDRA-7658) + * GCInspector more closely tracks GC; cassandra-stress and nodetool report it (CASSANDRA-7916) + * nodetool won't output bogus ownership info without a keyspace (CASSANDRA-7173) + * Add human readable option to nodetool commands (CASSANDRA-5433) + * Don't try to set repairedAt on old sstables (CASSANDRA-7913) + * Add metrics for tracking PreparedStatement use (CASSANDRA-7719) + * (cqlsh) tab-completion for triggers (CASSANDRA-7824) + * (cqlsh) Support for query paging (CASSANDRA-7514) + * (cqlsh) Show progress of COPY operations (CASSANDRA-7789) + * Add syntax to remove multiple elements from a map (CASSANDRA-6599) + * Support non-equals conditions in lightweight transactions (CASSANDRA-6839) + * Add IF [NOT] EXISTS to create/drop triggers (CASSANDRA-7606) + * (cqlsh) Display the current logged-in user (CASSANDRA-7785) + * (cqlsh) Don't ignore CTRL-C during COPY FROM execution (CASSANDRA-7815) + * (cqlsh) Order UDTs according to cross-type dependencies in DESCRIBE + output (CASSANDRA-7659) + * (cqlsh) Fix handling of CAS statement results (CASSANDRA-7671) + * (cqlsh) COPY TO/FROM improvements (CASSANDRA-7405) + * Support list index operations with conditions (CASSANDRA-7499) + * Add max live/tombstoned cells to nodetool cfstats output (CASSANDRA-7731) + * Validate IPv6 wildcard addresses properly (CASSANDRA-7680) + * (cqlsh) Error when tracing query (CASSANDRA-7613) + * Avoid IOOBE when building SyntaxError message snippet (CASSANDRA-7569) + * SSTableExport uses correct validator to create string representation of partition + keys (CASSANDRA-7498) + * Avoid NPEs when receiving type changes for an unknown keyspace (CASSANDRA-7689) + * Add support for custom 2i validation (CASSANDRA-7575) + * Pig support for hadoop CqlInputFormat (CASSANDRA-6454) + * Add listen_interface and rpc_interface options (CASSANDRA-7417) + * Improve schema merge performance (CASSANDRA-7444) + * Adjust MT depth based on # of partition validating (CASSANDRA-5263) + * Optimise NativeCell comparisons (CASSANDRA-6755) + * Configurable client timeout for cqlsh (CASSANDRA-7516) + * Include snippet of CQL query near syntax error in messages (CASSANDRA-7111) + * Make repair -pr work with -local (CASSANDRA-7450) + * Fix error in sstableloader with -cph > 1 (CASSANDRA
[2/6] git commit: Do not exit nodetool repair when receiving JMX NOTIF_LOST
Do not exit nodetool repair when receiving JMX NOTIF_LOST patch by yukim; reviewed by krummas for CASSANDRA-7909 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6eec29ed Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6eec29ed Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6eec29ed Branch: refs/heads/cassandra-2.1 Commit: 6eec29ed80de11e820dfcb0f3b3812553dd14246 Parents: 8952d6c Author: Yuki Morishita Authored: Wed Sep 10 13:24:32 2014 -0700 Committer: Yuki Morishita Committed: Mon Oct 6 13:05:20 2014 -0500 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/tools/NodeProbe.java | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6eec29ed/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 9914ad9..66d7e72 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -34,6 +34,7 @@ * Fix wrong progress when streaming uncompressed (CASSANDRA-7878) * Fix possible infinite loop in creating repair range (CASSANDRA-7983) * Fix unit in nodetool for streaming throughput (CASSANDRA-7375) + * Do not exit nodetool repair when receiving JMX NOTIF_LOST (CASSANDRA-7909) Merged from 1.2: * Don't index tombstones (CASSANDRA-7828) http://git-wip-us.apache.org/repos/asf/cassandra/blob/6eec29ed/src/java/org/apache/cassandra/tools/NodeProbe.java -- diff --git a/src/java/org/apache/cassandra/tools/NodeProbe.java b/src/java/org/apache/cassandra/tools/NodeProbe.java index d281219..78dce76 100644 --- a/src/java/org/apache/cassandra/tools/NodeProbe.java +++ b/src/java/org/apache/cassandra/tools/NodeProbe.java @@ -1109,8 +1109,6 @@ class RepairRunner implements NotificationListener format.format(notification.getTimeStamp()), keyspace); out.println(message); -success = false; -condition.signalAll(); } else if (JMXConnectionNotification.FAILED.equals(notification.getType()) || JMXConnectionNotification.CLOSED.equals(notification.getType()))
[1/6] git commit: Do not exit nodetool repair when receiving JMX NOTIF_LOST
Repository: cassandra Updated Branches: refs/heads/cassandra-2.0 8952d6ca9 -> 6eec29ed8 refs/heads/cassandra-2.1 a8052d7c8 -> af863d7d4 refs/heads/trunk bc246e132 -> 624918988 Do not exit nodetool repair when receiving JMX NOTIF_LOST patch by yukim; reviewed by krummas for CASSANDRA-7909 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6eec29ed Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6eec29ed Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6eec29ed Branch: refs/heads/cassandra-2.0 Commit: 6eec29ed80de11e820dfcb0f3b3812553dd14246 Parents: 8952d6c Author: Yuki Morishita Authored: Wed Sep 10 13:24:32 2014 -0700 Committer: Yuki Morishita Committed: Mon Oct 6 13:05:20 2014 -0500 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/tools/NodeProbe.java | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6eec29ed/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 9914ad9..66d7e72 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -34,6 +34,7 @@ * Fix wrong progress when streaming uncompressed (CASSANDRA-7878) * Fix possible infinite loop in creating repair range (CASSANDRA-7983) * Fix unit in nodetool for streaming throughput (CASSANDRA-7375) + * Do not exit nodetool repair when receiving JMX NOTIF_LOST (CASSANDRA-7909) Merged from 1.2: * Don't index tombstones (CASSANDRA-7828) http://git-wip-us.apache.org/repos/asf/cassandra/blob/6eec29ed/src/java/org/apache/cassandra/tools/NodeProbe.java -- diff --git a/src/java/org/apache/cassandra/tools/NodeProbe.java b/src/java/org/apache/cassandra/tools/NodeProbe.java index d281219..78dce76 100644 --- a/src/java/org/apache/cassandra/tools/NodeProbe.java +++ b/src/java/org/apache/cassandra/tools/NodeProbe.java @@ -1109,8 +1109,6 @@ class RepairRunner implements NotificationListener format.format(notification.getTimeStamp()), keyspace); out.println(message); -success = false; -condition.signalAll(); } else if (JMXConnectionNotification.FAILED.equals(notification.getType()) || JMXConnectionNotification.CLOSED.equals(notification.getType()))
[6/6] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/62491898 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/62491898 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/62491898 Branch: refs/heads/trunk Commit: 6249189884c4e76eb7ad8ce912fcaf2f98f84659 Parents: bc246e1 af863d7 Author: Yuki Morishita Authored: Mon Oct 6 13:06:42 2014 -0500 Committer: Yuki Morishita Committed: Mon Oct 6 13:06:42 2014 -0500 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/tools/NodeProbe.java | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/62491898/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/62491898/src/java/org/apache/cassandra/tools/NodeProbe.java --
[5/6] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/af863d7d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/af863d7d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/af863d7d Branch: refs/heads/cassandra-2.1 Commit: af863d7d4f7f0fa89f8f607250f7f82d84572f4e Parents: a8052d7 6eec29e Author: Yuki Morishita Authored: Mon Oct 6 13:06:33 2014 -0500 Committer: Yuki Morishita Committed: Mon Oct 6 13:06:33 2014 -0500 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/tools/NodeProbe.java | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/af863d7d/CHANGES.txt -- diff --cc CHANGES.txt index 7cce86e,66d7e72..e9e9fce --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,63 -1,4 +1,64 @@@ -2.0.11: +2.1.1 + * Properly track added size (CASSANDRA-7239) + * Allow compilation in java 8 (CASSANDRA-7208) + * Fix Assertion error on RangeTombstoneList diff (CASSANDRA-8013) + * Release references to overlapping sstables during compaction (CASSANDRA-7819) + * Send notification when opening compaction results early (CASSANDRA-8034) + * Make native server start block until properly bound (CASSANDRA-7885) + * (cqlsh) Fix IPv6 support (CASSANDRA-7988) + * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939) + * Make sstablerepairedset take a list of files (CASSANDRA-7995) + * (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972) + * (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891) + * Fix resource leak in event of corrupt sstable + * (cqlsh) Add command line option for cqlshrc file path (CASSANDRA-7131) + * Provide visibility into prepared statements churn (CASSANDRA-7921, CASSANDRA-7930) + * Invalidate prepared statements when their keyspace or table is + dropped (CASSANDRA-7566) + * cassandra-stress: fix support for NetworkTopologyStrategy (CASSANDRA-7945) + * Fix saving caches when a table is dropped (CASSANDRA-7784) + * Add better error checking of new stress profile (CASSANDRA-7716) + * Use ThreadLocalRandom and remove FBUtilities.threadLocalRandom (CASSANDRA-7934) + * Prevent operator mistakes due to simultaneous bootstrap (CASSANDRA-7069) + * cassandra-stress supports whitelist mode for node config (CASSANDRA-7658) + * GCInspector more closely tracks GC; cassandra-stress and nodetool report it (CASSANDRA-7916) + * nodetool won't output bogus ownership info without a keyspace (CASSANDRA-7173) + * Add human readable option to nodetool commands (CASSANDRA-5433) + * Don't try to set repairedAt on old sstables (CASSANDRA-7913) + * Add metrics for tracking PreparedStatement use (CASSANDRA-7719) + * (cqlsh) tab-completion for triggers (CASSANDRA-7824) + * (cqlsh) Support for query paging (CASSANDRA-7514) + * (cqlsh) Show progress of COPY operations (CASSANDRA-7789) + * Add syntax to remove multiple elements from a map (CASSANDRA-6599) + * Support non-equals conditions in lightweight transactions (CASSANDRA-6839) + * Add IF [NOT] EXISTS to create/drop triggers (CASSANDRA-7606) + * (cqlsh) Display the current logged-in user (CASSANDRA-7785) + * (cqlsh) Don't ignore CTRL-C during COPY FROM execution (CASSANDRA-7815) + * (cqlsh) Order UDTs according to cross-type dependencies in DESCRIBE + output (CASSANDRA-7659) + * (cqlsh) Fix handling of CAS statement results (CASSANDRA-7671) + * (cqlsh) COPY TO/FROM improvements (CASSANDRA-7405) + * Support list index operations with conditions (CASSANDRA-7499) + * Add max live/tombstoned cells to nodetool cfstats output (CASSANDRA-7731) + * Validate IPv6 wildcard addresses properly (CASSANDRA-7680) + * (cqlsh) Error when tracing query (CASSANDRA-7613) + * Avoid IOOBE when building SyntaxError message snippet (CASSANDRA-7569) + * SSTableExport uses correct validator to create string representation of partition + keys (CASSANDRA-7498) + * Avoid NPEs when receiving type changes for an unknown keyspace (CASSANDRA-7689) + * Add support for custom 2i validation (CASSANDRA-7575) + * Pig support for hadoop CqlInputFormat (CASSANDRA-6454) + * Add listen_interface and rpc_interface options (CASSANDRA-7417) + * Improve schema merge performance (CASSANDRA-7444) + * Adjust MT depth based on # of partition validating (CASSANDRA-5263) + * Optimise NativeCell comparisons (CASSANDRA-6755) + * Configurable client timeout for cqlsh (CASSANDRA-7516) + * Include snippet of CQL query near syntax error in messages (CASSANDRA-7111) + * Make repair -pr work with -local (CASSANDRA-7450) + * Fix error in sstableloader with -cph > 1 (C
[3/6] git commit: Do not exit nodetool repair when receiving JMX NOTIF_LOST
Do not exit nodetool repair when receiving JMX NOTIF_LOST patch by yukim; reviewed by krummas for CASSANDRA-7909 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6eec29ed Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6eec29ed Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6eec29ed Branch: refs/heads/trunk Commit: 6eec29ed80de11e820dfcb0f3b3812553dd14246 Parents: 8952d6c Author: Yuki Morishita Authored: Wed Sep 10 13:24:32 2014 -0700 Committer: Yuki Morishita Committed: Mon Oct 6 13:05:20 2014 -0500 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/tools/NodeProbe.java | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6eec29ed/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 9914ad9..66d7e72 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -34,6 +34,7 @@ * Fix wrong progress when streaming uncompressed (CASSANDRA-7878) * Fix possible infinite loop in creating repair range (CASSANDRA-7983) * Fix unit in nodetool for streaming throughput (CASSANDRA-7375) + * Do not exit nodetool repair when receiving JMX NOTIF_LOST (CASSANDRA-7909) Merged from 1.2: * Don't index tombstones (CASSANDRA-7828) http://git-wip-us.apache.org/repos/asf/cassandra/blob/6eec29ed/src/java/org/apache/cassandra/tools/NodeProbe.java -- diff --git a/src/java/org/apache/cassandra/tools/NodeProbe.java b/src/java/org/apache/cassandra/tools/NodeProbe.java index d281219..78dce76 100644 --- a/src/java/org/apache/cassandra/tools/NodeProbe.java +++ b/src/java/org/apache/cassandra/tools/NodeProbe.java @@ -1109,8 +1109,6 @@ class RepairRunner implements NotificationListener format.format(notification.getTimeStamp()), keyspace); out.println(message); -success = false; -condition.signalAll(); } else if (JMXConnectionNotification.FAILED.equals(notification.getType()) || JMXConnectionNotification.CLOSED.equals(notification.getType()))
[jira] [Resolved] (CASSANDRA-7909) Do not exit nodetool repair when receiving JMX NOTIF_LOST
[
https://issues.apache.org/jira/browse/CASSANDRA-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita resolved CASSANDRA-7909.
---
Resolution: Fixed
Committed, thanks!
> Do not exit nodetool repair when receiving JMX NOTIF_LOST
> -
>
> Key: CASSANDRA-7909
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7909
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Trivial
> Fix For: 2.0.11, 2.1.1
>
> Attachments:
> 0001-Do-not-quit-nodetool-when-JMX-notif_lost-received.patch
>
>
> {{nodetool repair}} prints out 'Lost notification...' and exits when JMX
> NOTIF_LOST message is received. But we should not exit right away since that
> message just indicates some messages are lost because "they arrive so fast
> that they cannot be delivered to the remote client quickly enough" according
> to
> https://weblogs.java.net/blog/emcmanus/archive/2007/08/when_can_jmx_no.html.
> So we should just continue to listen to events until repair finishes or
> connection is really closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7909) Do not exit nodetool repair when receiving JMX NOTIF_LOST
[
https://issues.apache.org/jira/browse/CASSANDRA-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160626#comment-14160626
]
Philip S Doctor commented on CASSANDRA-7909:
Hi, I have a question about this ticket.
Apologies if this is a poor question, I don't usually touch c* code.
NodeProbe is listening to notifications from StorageProxyMBean and JMX
connection notifications.
Let's say it loses notification that repair is complete. In this case, when
will the connection close? Does C* close the connection automatically when
repair is complete? If not it seems like this could be a problem.
> Do not exit nodetool repair when receiving JMX NOTIF_LOST
> -
>
> Key: CASSANDRA-7909
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7909
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Trivial
> Fix For: 2.0.11, 2.1.1
>
> Attachments:
> 0001-Do-not-quit-nodetool-when-JMX-notif_lost-received.patch
>
>
> {{nodetool repair}} prints out 'Lost notification...' and exits when JMX
> NOTIF_LOST message is received. But we should not exit right away since that
> message just indicates some messages are lost because "they arrive so fast
> that they cannot be delivered to the remote client quickly enough" according
> to
> https://weblogs.java.net/blog/emcmanus/archive/2007/08/when_can_jmx_no.html.
> So we should just continue to listen to events until repair finishes or
> connection is really closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7821) Add Optional Backoff on Retry to Cassandra Stress
[
https://issues.apache.org/jira/browse/CASSANDRA-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160697#comment-14160697
]
Russell Alexander Spitzer commented on CASSANDRA-7821:
--
We would have to write a new retry policy I think, the current ones retry
immediately which causes problems when we are testing under load. Sometimes a
node will become unresponsive temporarily and break the test but if we gave it
a bit of time it would come back online. If we retry as fast as possible then a
node which has stopped responding will stop the entire test.
Code i'm looking at for retry policies on the JD:
https://github.com/datastax/java-driver/blob/55b60db5767af26d4cf4618c495e0f760096c25c/driver-core/src/main/java/com/datastax/driver/core/policies/DefaultRetryPolicy.java
Of course writing a new retry policy would be acceptable too, a
BackingOffRetryPolicy.java or something alike?
> Add Optional Backoff on Retry to Cassandra Stress
> -
>
> Key: CASSANDRA-7821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7821
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Russell Alexander Spitzer
>Assignee: Russell Alexander Spitzer
> Attachments: CASSANDRA-7821-2.1.patch
>
>
> Currently when stress is running against a cluster which occasionally has
> nodes marked as down, it will almost immediately stop. This occurs because
> the retry loop can execute extremely quickly if each execution terminates
> with a {{com.datastax.driver.core.exceptions.NoHostAvailableException}} or
> {{com.datastax.driver.core.exceptions.UnavailableException}}.
> In case of these exceptions is will most likely be unable to succeed if the
> retries are performed as fast as possible. To get around this, we could add
> an optional delay on retries giving the cluster time to recover rather than
> terminating the stress run.
> We could make this configurable, with options such as:
> * Constant # Delays the same amount after each retry
> * Linear # Backoff a set amount * the trial number
> * Exponential # Backoff set amount * 2 ^ trial number
> This may also require adjusting the "thread is stuck check" to make sure that
> the max retry timeout will not cause the thread to be terminated early.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8064) What is the new "Academy" equivalent of the old "Java Development with Apache Cassandra" course?
[ https://issues.apache.org/jira/browse/CASSANDRA-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-8064. - Resolution: Invalid This question does not belong on the Apache Cassandra jira. I recommend asking datastax. > What is the new "Academy" equivalent of the old "Java Development with Apache > Cassandra" course? > > > Key: CASSANDRA-8064 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8064 > Project: Cassandra > Issue Type: Wish > Components: Documentation & website >Reporter: Darin Lewis >Priority: Minor > > What does DataStax recommend as the new "Academy" equivalent to the old "Java > Development with Apache Cassandra" course previously located on > https://datastaxacademy.elogiclearning.com/ ?? > Please advise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8064) What is the new "Academy" equivalent of the old "Java Development with Apache Cassandra" course?
Darin Lewis created CASSANDRA-8064: -- Summary: What is the new "Academy" equivalent of the old "Java Development with Apache Cassandra" course? Key: CASSANDRA-8064 URL: https://issues.apache.org/jira/browse/CASSANDRA-8064 Project: Cassandra Issue Type: Wish Components: Documentation & website Reporter: Darin Lewis Priority: Minor What does DataStax recommend as the new "Academy" equivalent to the old "Java Development with Apache Cassandra" course previously located on https://datastaxacademy.elogiclearning.com/ ?? Please advise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/2] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3afd0a86 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3afd0a86 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3afd0a86 Branch: refs/heads/trunk Commit: 3afd0a86d368bf86a727b61fb764bbf59a5bf7aa Parents: 6249189 b760990 Author: Joshua McKenzie Authored: Mon Oct 6 15:14:24 2014 -0500 Committer: Joshua McKenzie Committed: Mon Oct 6 15:14:24 2014 -0500 -- conf/cassandra-env.ps1 | 73 + 1 file changed, 73 insertions(+) --
git commit: Warn on startup if swap file enabled on Windows
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 af863d7d4 -> b7609903b
Warn on startup if swap file enabled on Windows
patch by Josh McKenzie; reviewed by Philip Thompson for CASSANDRA-7316
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b7609903
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b7609903
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b7609903
Branch: refs/heads/cassandra-2.1
Commit: b7609903b0046031c6a54f1ee93a785348472df1
Parents: af863d7
Author: Joshua McKenzie
Authored: Mon Oct 6 15:13:10 2014 -0500
Committer: Joshua McKenzie
Committed: Mon Oct 6 15:13:10 2014 -0500
--
conf/cassandra-env.ps1 | 73 +
1 file changed, 73 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b7609903/conf/cassandra-env.ps1
--
diff --git a/conf/cassandra-env.ps1 b/conf/cassandra-env.ps1
index 168f322..47f4fa3 100644
--- a/conf/cassandra-env.ps1
+++ b/conf/cassandra-env.ps1
@@ -54,6 +54,79 @@ Function BuildClassPath
#-
Function CalculateHeapSizes
{
+# Check if swapping is enabled on the host and warn if so - reference
CASSANDRA-7316
+
+$osInfo = Get-WmiObject -class "Win32_computersystem"
+$autoPage = $osInfo.AutomaticManagedPageFile
+
+if ($autoPage)
+{
+echo
"*-*"
+echo
"*-*"
+echo ""
+echo "WARNING! Automatic page file configuration detected."
+echo "It is recommended that you disable swap when running
Cassandra"
+echo "for performance and stability reasons."
+echo ""
+echo
"*-*"
+echo
"*-*"
+}
+else
+{
+$pageFileInfo = Get-WmiObject -class "Win32_PageFileSetting"
-EnableAllPrivileges
+$pageFileCount = $PageFileInfo.Count
+if ($pageFileInfo)
+{
+$files = @()
+$sizes = @()
+$hasSizes = $FALSE
+
+# PageFileCount isn't populated and obj comes back as single if
there's only 1
+if ([string]::IsNullOrEmpty($PageFileCount))
+{
+$PageFileCount = 1
+$files += $PageFileInfo.Name
+if ($PageFileInfo.MaximumSize -ne 0)
+{
+$hasSizes = $TRUE
+$sizes += $PageFileInfo.MaximumSize
+}
+}
+else
+{
+for ($i = 0; $i -le $PageFileCount; $i++)
+{
+$files += $PageFileInfo[$i].Name
+if ($PageFileInfo[$i].MaximumSize -ne 0)
+{
+$hasSizes = $TRUE
+$sizes += $PageFileInfo[$i].MaximumSize
+}
+}
+}
+
+echo
"*-*"
+echo
"*-*"
+echo ""
+echo "WARNING! $PageFileCount swap file(s) detected"
+for ($i = 0; $i -lt $PageFileCount; $i++)
+{
+$toPrint = "Name: " + $files[$i]
+if ($hasSizes)
+{
+$toPrint = $toPrint + " Size: " + $sizes[$i]
+$toPrint = $toPrint -replace [Environment]::NewLine, ""
+}
+echo $toPrint
+}
+echo "It is recommended that you disable swap when running
Cassandra"
+echo "for performance and stability reasons."
+echo ""
+echo
"*-*"
+echo
"*-*"
+}
+}
+
# Validate that we need to run this function and that our config is good
if ($env:MAX_HEAP_SIZE -and $env:HEAP_NEWSIZE)
{
[1/2] git commit: Warn on startup if swap file enabled on Windows
Repository: cassandra
Updated Branches:
refs/heads/trunk 624918988 -> 3afd0a86d
Warn on startup if swap file enabled on Windows
patch by Josh McKenzie; reviewed by Philip Thompson for CASSANDRA-7316
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b7609903
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b7609903
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b7609903
Branch: refs/heads/trunk
Commit: b7609903b0046031c6a54f1ee93a785348472df1
Parents: af863d7
Author: Joshua McKenzie
Authored: Mon Oct 6 15:13:10 2014 -0500
Committer: Joshua McKenzie
Committed: Mon Oct 6 15:13:10 2014 -0500
--
conf/cassandra-env.ps1 | 73 +
1 file changed, 73 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b7609903/conf/cassandra-env.ps1
--
diff --git a/conf/cassandra-env.ps1 b/conf/cassandra-env.ps1
index 168f322..47f4fa3 100644
--- a/conf/cassandra-env.ps1
+++ b/conf/cassandra-env.ps1
@@ -54,6 +54,79 @@ Function BuildClassPath
#-
Function CalculateHeapSizes
{
+# Check if swapping is enabled on the host and warn if so - reference
CASSANDRA-7316
+
+$osInfo = Get-WmiObject -class "Win32_computersystem"
+$autoPage = $osInfo.AutomaticManagedPageFile
+
+if ($autoPage)
+{
+echo
"*-*"
+echo
"*-*"
+echo ""
+echo "WARNING! Automatic page file configuration detected."
+echo "It is recommended that you disable swap when running
Cassandra"
+echo "for performance and stability reasons."
+echo ""
+echo
"*-*"
+echo
"*-*"
+}
+else
+{
+$pageFileInfo = Get-WmiObject -class "Win32_PageFileSetting"
-EnableAllPrivileges
+$pageFileCount = $PageFileInfo.Count
+if ($pageFileInfo)
+{
+$files = @()
+$sizes = @()
+$hasSizes = $FALSE
+
+# PageFileCount isn't populated and obj comes back as single if
there's only 1
+if ([string]::IsNullOrEmpty($PageFileCount))
+{
+$PageFileCount = 1
+$files += $PageFileInfo.Name
+if ($PageFileInfo.MaximumSize -ne 0)
+{
+$hasSizes = $TRUE
+$sizes += $PageFileInfo.MaximumSize
+}
+}
+else
+{
+for ($i = 0; $i -le $PageFileCount; $i++)
+{
+$files += $PageFileInfo[$i].Name
+if ($PageFileInfo[$i].MaximumSize -ne 0)
+{
+$hasSizes = $TRUE
+$sizes += $PageFileInfo[$i].MaximumSize
+}
+}
+}
+
+echo
"*-*"
+echo
"*-*"
+echo ""
+echo "WARNING! $PageFileCount swap file(s) detected"
+for ($i = 0; $i -lt $PageFileCount; $i++)
+{
+$toPrint = "Name: " + $files[$i]
+if ($hasSizes)
+{
+$toPrint = $toPrint + " Size: " + $sizes[$i]
+$toPrint = $toPrint -replace [Environment]::NewLine, ""
+}
+echo $toPrint
+}
+echo "It is recommended that you disable swap when running
Cassandra"
+echo "for performance and stability reasons."
+echo ""
+echo
"*-*"
+echo
"*-*"
+}
+}
+
# Validate that we need to run this function and that our config is good
if ($env:MAX_HEAP_SIZE -and $env:HEAP_NEWSIZE)
{
[jira] [Commented] (CASSANDRA-6455) Improve concurrency of repair process
[ https://issues.apache.org/jira/browse/CASSANDRA-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160883#comment-14160883 ] Yuki Morishita commented on CASSANDRA-6455: --- Pushed the latest to here: https://github.com/yukim/cassandra/tree/6455 > Improve concurrency of repair process > - > > Key: CASSANDRA-6455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6455 > Project: Cassandra > Issue Type: Improvement >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Minor > Fix For: 3.0 > > Attachments: 6455-3.0-v2.txt, 6455-3.0.txt, 6455.txt > > > Currently, most of the repair tasks (taking snapshots, send/receiving merkle > tree, compute MT difference, etc) are done on single threaded > AntiEntropyStage. > This causes a problem like CASSANDRA-6415 and likely to cause unnecessary > wait. > Also, repair is done one CF at the time. I think we can parallelize > this(concurrency is configurable by a user based on # of CF and load of the > nodes) for faster processing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160882#comment-14160882 ] Paulo Motta commented on CASSANDRA-2388: http://mail-archives.apache.org/mod_mbox/cassandra-dev/201410.mbox/%3CCALdd-zjmvp7JOtguZ_k951RQHDtFt1cthX=RnHQ332C=gaz...@mail.gmail.com%3E > ColumnFamilyRecordReader fails for a given split because a host is down, even > if records could reasonably be read from other replica. > - > > Key: CASSANDRA-2388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 0.6 >Reporter: Eldon Stegall >Assignee: Paulo Motta >Priority: Minor > Labels: hadoop, inputformat > Fix For: 2.0.11 > > Attachments: 0002_On_TException_try_next_split.patch, > 1.2-CASSANDRA-2388.patch, 2.0-CASSANDRA-2388-v2.patch, > 2.0-CASSANDRA-2388.patch, CASSANDRA-2388-addition1.patch, > CASSANDRA-2388-extended.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, > CASSANDRA-2388.patch, CASSANDRA-2388.patch > > > ColumnFamilyRecordReader only tries the first location for a given split. We > should try multiple locations for a given split. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
[
https://issues.apache.org/jira/browse/CASSANDRA-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-8019:
---
Attachment: 8019_v2.txt
After chewing on this a bit, I've come to the conclusion that the problem here
isn't really the order of deletion or even the pre-3.0 behavior as those files
are *eventually* successfully deleted on a subsequent GC. Our problem is that
we're logging this as an error immediately on 1st failure on Windows when we
expect there to be some contention on ordering pre-CASSANDRA-4050 and it's not
really an error condition.
Having said that, we want to still log on legitimate error conditions so
suppressing or dropping to WARN wouldn't be appropriate in those cases.
I've attached a v2 patch against 2.0 that adds a retryCount to our
SSTableDeletingTask that will print the error message after 3 failed deletion
attempts and reset the counter, only if on Windows. Behavior on Linux remains
at 1 failed deletion == logged. v2 quiets all deletion errors in unit tests on
2.0 and 2.1 but should leave room for genuine locked / undeletable files to log
after a few failures. I should note: 3 is a completely arbitrary number, and
relying on GC for eventual file deletion is of course not ideal.
Thoughts [~jbellis]? I'd prefer we nip this in the bud as this 'Unable to
delete' error is getting more prevalent on the 2.1 branch as we make further
changes and optimizations, and I'm more comfortable loosening up the logging
criteria for this error than retrofitting more reference counting or making
changes to scanner close ordering throughout the code-base.
> Windows Unit tests and Dtests erroring due to sstable deleting task error
> -
>
> Key: CASSANDRA-8019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Labels: windows
> Fix For: 2.1.1
>
> Attachments: 8019_aggressive_v1.txt, 8019_conservative_v1.txt,
> 8019_v2.txt
>
>
> Currently a large number of dtests and unit tests are erroring on windows
> with the following error in the node log:
> {code}
> ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383
> SSTableDeletingTask.java:89 - Unable to delete
> c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
> (it will be removed on server restart; we'll also retry after GC)\n
> {code}
> git bisect points to the following commit:
> {code}
> 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
> commit 0e831007760bffced8687f51b99525b650d7e193
> Author: Benedict Elliott Smith
> Date: Fri Sep 19 18:17:19 2014 +0100
> Fix resource leak in event of corrupt sstable
> patch by benedict; review by yukim for CASSANDRA-7932
> :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
> f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
> :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
> 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
> :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
> de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
> {code}
> You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
[
https://issues.apache.org/jira/browse/CASSANDRA-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-8019:
---
Attachment: (was: 8019_v2.txt)
> Windows Unit tests and Dtests erroring due to sstable deleting task error
> -
>
> Key: CASSANDRA-8019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Labels: windows
> Fix For: 2.1.1
>
> Attachments: 8019_aggressive_v1.txt, 8019_conservative_v1.txt
>
>
> Currently a large number of dtests and unit tests are erroring on windows
> with the following error in the node log:
> {code}
> ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383
> SSTableDeletingTask.java:89 - Unable to delete
> c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
> (it will be removed on server restart; we'll also retry after GC)\n
> {code}
> git bisect points to the following commit:
> {code}
> 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
> commit 0e831007760bffced8687f51b99525b650d7e193
> Author: Benedict Elliott Smith
> Date: Fri Sep 19 18:17:19 2014 +0100
> Fix resource leak in event of corrupt sstable
> patch by benedict; review by yukim for CASSANDRA-7932
> :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
> f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
> :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
> 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
> :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
> de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
> {code}
> You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
[
https://issues.apache.org/jira/browse/CASSANDRA-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-8019:
---
Attachment: 8019_v2.txt
Slight tweak to v2 logging message.
> Windows Unit tests and Dtests erroring due to sstable deleting task error
> -
>
> Key: CASSANDRA-8019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Labels: windows
> Fix For: 2.1.1
>
> Attachments: 8019_aggressive_v1.txt, 8019_conservative_v1.txt,
> 8019_v2.txt
>
>
> Currently a large number of dtests and unit tests are erroring on windows
> with the following error in the node log:
> {code}
> ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383
> SSTableDeletingTask.java:89 - Unable to delete
> c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
> (it will be removed on server restart; we'll also retry after GC)\n
> {code}
> git bisect points to the following commit:
> {code}
> 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
> commit 0e831007760bffced8687f51b99525b650d7e193
> Author: Benedict Elliott Smith
> Date: Fri Sep 19 18:17:19 2014 +0100
> Fix resource leak in event of corrupt sstable
> patch by benedict; review by yukim for CASSANDRA-7932
> :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
> f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
> :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
> 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
> :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
> de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
> {code}
> You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
git commit: SSL does not work in cassandra-cli.
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 6eec29ed8 -> df046dfe0
SSL does not work in cassandra-cli.
patch by jasobrown, reviewed by beobal for CASSANDRA-7899
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/df046dfe
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/df046dfe
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/df046dfe
Branch: refs/heads/cassandra-2.0
Commit: df046dfe092ea5a08ec0e29a00d30423284d1f86
Parents: 6eec29e
Author: Jason Brown
Authored: Mon Oct 6 14:44:51 2014 -0700
Committer: Jason Brown
Committed: Mon Oct 6 14:44:51 2014 -0700
--
CHANGES.txt | 1 +
.../cli/transport/FramedTransportFactory.java | 32 -
.../cli/transport/SSLTransportFactory.java | 47
.../cassandra/thrift/SSLTransportFactory.java | 6 +--
4 files changed, 4 insertions(+), 82 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df046dfe/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 66d7e72..c811ebf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.11:
+ * SSL does not work in cassandra-cli (CASSANDRA-7899)
* Fix potential exception when using ReversedType in DynamicCompositeType
(CASSANDRA-7898)
* Better validation of collection values (CASSANDRA-7833)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df046dfe/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
--
diff --git
a/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
b/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
deleted file mode 100644
index dc7ef81..000
--- a/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
+++ /dev/null
@@ -1,32 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.cli.transport;
-
-import org.apache.thrift.transport.TFramedTransport;
-import org.apache.thrift.transport.TTransport;
-import org.apache.thrift.transport.TTransportFactory;
-
-public class FramedTransportFactory extends TTransportFactory
-{
-public static final int DEFAULT_MAX_FRAME_SIZE = 15 * 1024 * 1024; // 15
MiB
-
-public TTransport getTransport(TTransport base)
-{
-return new TFramedTransport(base, DEFAULT_MAX_FRAME_SIZE);
-}
-}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df046dfe/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
--
diff --git
a/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
b/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
deleted file mode 100644
index 4aa9fc1..000
--- a/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
+++ /dev/null
@@ -1,47 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.cli.transport;
-
-import org.apache.cassandra.cli.CliMain;
-import org.apache.cassandra.cli.CliSessionState;
-import org.apache.thrift.transport.TSSLTranspor
[2/2] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/26016046 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/26016046 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/26016046 Branch: refs/heads/cassandra-2.1 Commit: 2601604695e421dd056601b1d84a35bf58809a1e Parents: b760990 df046df Author: Jason Brown Authored: Mon Oct 6 14:54:25 2014 -0700 Committer: Jason Brown Committed: Mon Oct 6 14:54:25 2014 -0700 -- CHANGES.txt | 1 + .../cli/transport/FramedTransportFactory.java | 32 - .../cli/transport/SSLTransportFactory.java | 47 .../cassandra/thrift/SSLTransportFactory.java | 5 ++- 4 files changed, 4 insertions(+), 81 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/26016046/CHANGES.txt -- diff --cc CHANGES.txt index e9e9fce,c811ebf..f9523ed --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,64 -1,5 +1,65 @@@ -2.0.11: +2.1.1 + * Properly track added size (CASSANDRA-7239) + * Allow compilation in java 8 (CASSANDRA-7208) + * Fix Assertion error on RangeTombstoneList diff (CASSANDRA-8013) + * Release references to overlapping sstables during compaction (CASSANDRA-7819) + * Send notification when opening compaction results early (CASSANDRA-8034) + * Make native server start block until properly bound (CASSANDRA-7885) + * (cqlsh) Fix IPv6 support (CASSANDRA-7988) + * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939) + * Make sstablerepairedset take a list of files (CASSANDRA-7995) + * (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972) + * (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891) + * Fix resource leak in event of corrupt sstable + * (cqlsh) Add command line option for cqlshrc file path (CASSANDRA-7131) + * Provide visibility into prepared statements churn (CASSANDRA-7921, CASSANDRA-7930) + * Invalidate prepared statements when their keyspace or table is + dropped (CASSANDRA-7566) + * cassandra-stress: fix support for NetworkTopologyStrategy (CASSANDRA-7945) + * Fix saving caches when a table is dropped (CASSANDRA-7784) + * Add better error checking of new stress profile (CASSANDRA-7716) + * Use ThreadLocalRandom and remove FBUtilities.threadLocalRandom (CASSANDRA-7934) + * Prevent operator mistakes due to simultaneous bootstrap (CASSANDRA-7069) + * cassandra-stress supports whitelist mode for node config (CASSANDRA-7658) + * GCInspector more closely tracks GC; cassandra-stress and nodetool report it (CASSANDRA-7916) + * nodetool won't output bogus ownership info without a keyspace (CASSANDRA-7173) + * Add human readable option to nodetool commands (CASSANDRA-5433) + * Don't try to set repairedAt on old sstables (CASSANDRA-7913) + * Add metrics for tracking PreparedStatement use (CASSANDRA-7719) + * (cqlsh) tab-completion for triggers (CASSANDRA-7824) + * (cqlsh) Support for query paging (CASSANDRA-7514) + * (cqlsh) Show progress of COPY operations (CASSANDRA-7789) + * Add syntax to remove multiple elements from a map (CASSANDRA-6599) + * Support non-equals conditions in lightweight transactions (CASSANDRA-6839) + * Add IF [NOT] EXISTS to create/drop triggers (CASSANDRA-7606) + * (cqlsh) Display the current logged-in user (CASSANDRA-7785) + * (cqlsh) Don't ignore CTRL-C during COPY FROM execution (CASSANDRA-7815) + * (cqlsh) Order UDTs according to cross-type dependencies in DESCRIBE + output (CASSANDRA-7659) + * (cqlsh) Fix handling of CAS statement results (CASSANDRA-7671) + * (cqlsh) COPY TO/FROM improvements (CASSANDRA-7405) + * Support list index operations with conditions (CASSANDRA-7499) + * Add max live/tombstoned cells to nodetool cfstats output (CASSANDRA-7731) + * Validate IPv6 wildcard addresses properly (CASSANDRA-7680) + * (cqlsh) Error when tracing query (CASSANDRA-7613) + * Avoid IOOBE when building SyntaxError message snippet (CASSANDRA-7569) + * SSTableExport uses correct validator to create string representation of partition + keys (CASSANDRA-7498) + * Avoid NPEs when receiving type changes for an unknown keyspace (CASSANDRA-7689) + * Add support for custom 2i validation (CASSANDRA-7575) + * Pig support for hadoop CqlInputFormat (CASSANDRA-6454) + * Add listen_interface and rpc_interface options (CASSANDRA-7417) + * Improve schema merge performance (CASSANDRA-7444) + * Adjust MT depth based on # of partition validating (CASSANDRA-5263) + * Optimise NativeCell comparisons (CASSANDRA-6755) + * Configurable client timeout for cqlsh (CASSANDRA-7516) + * Include snippet of CQL query near syntax er
[1/2] git commit: SSL does not work in cassandra-cli.
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 b7609903b -> 260160469
SSL does not work in cassandra-cli.
patch by jasobrown, reviewed by beobal for CASSANDRA-7899
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/df046dfe
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/df046dfe
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/df046dfe
Branch: refs/heads/cassandra-2.1
Commit: df046dfe092ea5a08ec0e29a00d30423284d1f86
Parents: 6eec29e
Author: Jason Brown
Authored: Mon Oct 6 14:44:51 2014 -0700
Committer: Jason Brown
Committed: Mon Oct 6 14:44:51 2014 -0700
--
CHANGES.txt | 1 +
.../cli/transport/FramedTransportFactory.java | 32 -
.../cli/transport/SSLTransportFactory.java | 47
.../cassandra/thrift/SSLTransportFactory.java | 6 +--
4 files changed, 4 insertions(+), 82 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df046dfe/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 66d7e72..c811ebf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.11:
+ * SSL does not work in cassandra-cli (CASSANDRA-7899)
* Fix potential exception when using ReversedType in DynamicCompositeType
(CASSANDRA-7898)
* Better validation of collection values (CASSANDRA-7833)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df046dfe/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
--
diff --git
a/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
b/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
deleted file mode 100644
index dc7ef81..000
--- a/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
+++ /dev/null
@@ -1,32 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.cli.transport;
-
-import org.apache.thrift.transport.TFramedTransport;
-import org.apache.thrift.transport.TTransport;
-import org.apache.thrift.transport.TTransportFactory;
-
-public class FramedTransportFactory extends TTransportFactory
-{
-public static final int DEFAULT_MAX_FRAME_SIZE = 15 * 1024 * 1024; // 15
MiB
-
-public TTransport getTransport(TTransport base)
-{
-return new TFramedTransport(base, DEFAULT_MAX_FRAME_SIZE);
-}
-}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df046dfe/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
--
diff --git
a/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
b/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
deleted file mode 100644
index 4aa9fc1..000
--- a/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
+++ /dev/null
@@ -1,47 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.cli.transport;
-
-import org.apache.cassandra.cli.CliMain;
-import org.apache.cassandra.cli.CliSessionState;
-import org.apache.thrift.transport.TSSLTranspor
[2/3] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/26016046 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/26016046 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/26016046 Branch: refs/heads/trunk Commit: 2601604695e421dd056601b1d84a35bf58809a1e Parents: b760990 df046df Author: Jason Brown Authored: Mon Oct 6 14:54:25 2014 -0700 Committer: Jason Brown Committed: Mon Oct 6 14:54:25 2014 -0700 -- CHANGES.txt | 1 + .../cli/transport/FramedTransportFactory.java | 32 - .../cli/transport/SSLTransportFactory.java | 47 .../cassandra/thrift/SSLTransportFactory.java | 5 ++- 4 files changed, 4 insertions(+), 81 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/26016046/CHANGES.txt -- diff --cc CHANGES.txt index e9e9fce,c811ebf..f9523ed --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,64 -1,5 +1,65 @@@ -2.0.11: +2.1.1 + * Properly track added size (CASSANDRA-7239) + * Allow compilation in java 8 (CASSANDRA-7208) + * Fix Assertion error on RangeTombstoneList diff (CASSANDRA-8013) + * Release references to overlapping sstables during compaction (CASSANDRA-7819) + * Send notification when opening compaction results early (CASSANDRA-8034) + * Make native server start block until properly bound (CASSANDRA-7885) + * (cqlsh) Fix IPv6 support (CASSANDRA-7988) + * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939) + * Make sstablerepairedset take a list of files (CASSANDRA-7995) + * (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972) + * (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891) + * Fix resource leak in event of corrupt sstable + * (cqlsh) Add command line option for cqlshrc file path (CASSANDRA-7131) + * Provide visibility into prepared statements churn (CASSANDRA-7921, CASSANDRA-7930) + * Invalidate prepared statements when their keyspace or table is + dropped (CASSANDRA-7566) + * cassandra-stress: fix support for NetworkTopologyStrategy (CASSANDRA-7945) + * Fix saving caches when a table is dropped (CASSANDRA-7784) + * Add better error checking of new stress profile (CASSANDRA-7716) + * Use ThreadLocalRandom and remove FBUtilities.threadLocalRandom (CASSANDRA-7934) + * Prevent operator mistakes due to simultaneous bootstrap (CASSANDRA-7069) + * cassandra-stress supports whitelist mode for node config (CASSANDRA-7658) + * GCInspector more closely tracks GC; cassandra-stress and nodetool report it (CASSANDRA-7916) + * nodetool won't output bogus ownership info without a keyspace (CASSANDRA-7173) + * Add human readable option to nodetool commands (CASSANDRA-5433) + * Don't try to set repairedAt on old sstables (CASSANDRA-7913) + * Add metrics for tracking PreparedStatement use (CASSANDRA-7719) + * (cqlsh) tab-completion for triggers (CASSANDRA-7824) + * (cqlsh) Support for query paging (CASSANDRA-7514) + * (cqlsh) Show progress of COPY operations (CASSANDRA-7789) + * Add syntax to remove multiple elements from a map (CASSANDRA-6599) + * Support non-equals conditions in lightweight transactions (CASSANDRA-6839) + * Add IF [NOT] EXISTS to create/drop triggers (CASSANDRA-7606) + * (cqlsh) Display the current logged-in user (CASSANDRA-7785) + * (cqlsh) Don't ignore CTRL-C during COPY FROM execution (CASSANDRA-7815) + * (cqlsh) Order UDTs according to cross-type dependencies in DESCRIBE + output (CASSANDRA-7659) + * (cqlsh) Fix handling of CAS statement results (CASSANDRA-7671) + * (cqlsh) COPY TO/FROM improvements (CASSANDRA-7405) + * Support list index operations with conditions (CASSANDRA-7499) + * Add max live/tombstoned cells to nodetool cfstats output (CASSANDRA-7731) + * Validate IPv6 wildcard addresses properly (CASSANDRA-7680) + * (cqlsh) Error when tracing query (CASSANDRA-7613) + * Avoid IOOBE when building SyntaxError message snippet (CASSANDRA-7569) + * SSTableExport uses correct validator to create string representation of partition + keys (CASSANDRA-7498) + * Avoid NPEs when receiving type changes for an unknown keyspace (CASSANDRA-7689) + * Add support for custom 2i validation (CASSANDRA-7575) + * Pig support for hadoop CqlInputFormat (CASSANDRA-6454) + * Add listen_interface and rpc_interface options (CASSANDRA-7417) + * Improve schema merge performance (CASSANDRA-7444) + * Adjust MT depth based on # of partition validating (CASSANDRA-5263) + * Optimise NativeCell comparisons (CASSANDRA-6755) + * Configurable client timeout for cqlsh (CASSANDRA-7516) + * Include snippet of CQL query near syntax error in m
[1/3] git commit: SSL does not work in cassandra-cli.
Repository: cassandra
Updated Branches:
refs/heads/trunk 3afd0a86d -> f72668552
SSL does not work in cassandra-cli.
patch by jasobrown, reviewed by beobal for CASSANDRA-7899
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/df046dfe
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/df046dfe
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/df046dfe
Branch: refs/heads/trunk
Commit: df046dfe092ea5a08ec0e29a00d30423284d1f86
Parents: 6eec29e
Author: Jason Brown
Authored: Mon Oct 6 14:44:51 2014 -0700
Committer: Jason Brown
Committed: Mon Oct 6 14:44:51 2014 -0700
--
CHANGES.txt | 1 +
.../cli/transport/FramedTransportFactory.java | 32 -
.../cli/transport/SSLTransportFactory.java | 47
.../cassandra/thrift/SSLTransportFactory.java | 6 +--
4 files changed, 4 insertions(+), 82 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df046dfe/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 66d7e72..c811ebf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.11:
+ * SSL does not work in cassandra-cli (CASSANDRA-7899)
* Fix potential exception when using ReversedType in DynamicCompositeType
(CASSANDRA-7898)
* Better validation of collection values (CASSANDRA-7833)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df046dfe/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
--
diff --git
a/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
b/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
deleted file mode 100644
index dc7ef81..000
--- a/src/java/org/apache/cassandra/cli/transport/FramedTransportFactory.java
+++ /dev/null
@@ -1,32 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.cli.transport;
-
-import org.apache.thrift.transport.TFramedTransport;
-import org.apache.thrift.transport.TTransport;
-import org.apache.thrift.transport.TTransportFactory;
-
-public class FramedTransportFactory extends TTransportFactory
-{
-public static final int DEFAULT_MAX_FRAME_SIZE = 15 * 1024 * 1024; // 15
MiB
-
-public TTransport getTransport(TTransport base)
-{
-return new TFramedTransport(base, DEFAULT_MAX_FRAME_SIZE);
-}
-}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df046dfe/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
--
diff --git
a/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
b/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
deleted file mode 100644
index 4aa9fc1..000
--- a/src/java/org/apache/cassandra/cli/transport/SSLTransportFactory.java
+++ /dev/null
@@ -1,47 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.cli.transport;
-
-import org.apache.cassandra.cli.CliMain;
-import org.apache.cassandra.cli.CliSessionState;
-import org.apache.thrift.transport.TSSLTransportFactory;
-impor
[3/3] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Conflicts: src/java/org/apache/cassandra/thrift/SSLTransportFactory.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f7266855 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f7266855 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f7266855 Branch: refs/heads/trunk Commit: f7266855218b8e9eb34a62ad933c4ed889a71c64 Parents: 3afd0a8 2601604 Author: Jason Brown Authored: Mon Oct 6 14:56:35 2014 -0700 Committer: Jason Brown Committed: Mon Oct 6 14:56:35 2014 -0700 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/thrift/SSLTransportFactory.java | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f7266855/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f7266855/src/java/org/apache/cassandra/thrift/SSLTransportFactory.java --
[jira] [Commented] (CASSANDRA-7899) SSL does not work in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161044#comment-14161044 ] Jason Brown commented on CASSANDRA-7899: Oops, nice catch on my laziness [~beobal]. +1 on v2, and committed. > SSL does not work in cassandra-cli > -- > > Key: CASSANDRA-7899 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7899 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Linux 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 > 21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > java version "1.7.0_17" > Java(TM) SE Runtime Environment (build 1.7.0_17-b02) > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) > [cqlsh 4.1.1 | Cassandra 2.0.10 | CQL spec 3.1.1 | Thrift protocol 19.39.0] >Reporter: Zdenek Ott >Assignee: Jason Brown > Attachments: 7899-v1.txt, 7899-v2.txt > > > When specify transport factory parameter '-tf > org.apache.cassandra.cli.transport.SSLTransportFactory' it throws exception, > see below, because SSLTransportFactory extends TTransportFactory not > ITransportFactory. > Exception in thread "main" java.lang.IllegalArgumentException: Cannot create > a transport factory 'org.apache.cassandra.cli.transport.SSLTransportFactory'. > at > org.apache.cassandra.cli.CliOptions.validateAndSetTransportFactory(CliOptions.java:288) > at > org.apache.cassandra.cli.CliOptions.processArgs(CliOptions.java:223) > at org.apache.cassandra.cli.CliMain.main(CliMain.java:230) > Caused by: java.lang.IllegalArgumentException: transport factory > 'org.apache.cassandra.cli.transport.SSLTransportFactory' not derived from > ITransportFactory > at > org.apache.cassandra.cli.CliOptions.validateAndSetTransportFactory(CliOptions.java:282) > ... 2 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8065) Mutationstage error, ThreadPoolExecutor has shut down
Vishal Mehta created CASSANDRA-8065:
---
Summary: Mutationstage error, ThreadPoolExecutor has shut down
Key: CASSANDRA-8065
URL: https://issues.apache.org/jira/browse/CASSANDRA-8065
Project: Cassandra
Issue Type: Bug
Environment: Casssandra Version: 2.0.9
Total Clusters/Datacenters: 3
Nodes in each cluster: 4
Total # of Nodes: 12
Replication Factor:3 for each data center
Node Size of each cluster: C3.xlarge in EC2
Reporter: Vishal Mehta
1. Writes running at about 120 qps w/ TTL at row level for 60 minutes (for 3
column families)
2. GC set to run at every 10 minutes (so that we claim our space back from
tombstones)
3. Other settings set as default.
After some time (1 hour 30 minutes approximately of tests execution) 11 nodes
across datacenters are Down. And write tests fails, with following exception in
/var/log/cassandra/system.log.
{noformat}
ERROR [MutationStage:18098] 2014-10-04 01:05:36,525 CassandraDaemon.java (line
199) Exception in thread Thread[MutationStage:18098,5,main]
java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
down
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:145)
at
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:110)
at
org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:893)
at
org.apache.cassandra.service.StorageProxy.access$300(StorageProxy.java:68)
at
org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:1958)
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:724)
WARN [StorageServiceShutdownHook] 2014-10-04 01:05:36,525 StorageProxy.java
(line 2031) Some hints were not written before shutdown. This is not supposed
to happen. You should (a) run repair, and (b) file a bug report
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7881) SCHEMA_CHANGE Events and Responses should carry the Schema Version
[
https://issues.apache.org/jira/browse/CASSANDRA-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161189#comment-14161189
]
Michael Penick commented on CASSANDRA-7881:
---
This also has practical implications. If you had the current version UUID then
any node could be use to verify schema agreement. Currently, the same node
where the change was made has to be used to verify agreement.
> SCHEMA_CHANGE Events and Responses should carry the Schema Version
> --
>
> Key: CASSANDRA-7881
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7881
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Michaël Figuière
>Priority: Minor
> Labels: protocolv4
>
> For similar logging and debugging purpose as exposed in CASSANDRA-7880, it
> would be helpful to send to the client the previous and new schema version
> UUID that were in use before and after a schema change operation, in the
> {{SCHEMA_CHANGE}} events and responses in the protocol v4.
> This could then be exposed in the client APIs in order to bring much more
> precise awareness of the actual status of the schema on each node.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7460) Send source sstable level when bootstrapping or replacing nodes
[ https://issues.apache.org/jira/browse/CASSANDRA-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161235#comment-14161235 ] sankalp kohli commented on CASSANDRA-7460: -- [~krummas] The patch is not applying to trunk. Can you please update new one. > Send source sstable level when bootstrapping or replacing nodes > --- > > Key: CASSANDRA-7460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7460 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0 > > Attachments: 0001-wip-keep-sstable-level-when-bootstrapping.patch > > > When replacing or bootstrapping a new node we can keep the source sstable > level to avoid doing alot of compaction after bootstrap -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8004) Run LCS for both repaired and unrepaired data
[ https://issues.apache.org/jira/browse/CASSANDRA-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161250#comment-14161250 ] sankalp kohli commented on CASSANDRA-8004: -- Good idea. So if Level 2 stable is repaired, you will find all overlapping stables in L2 repaired and compact them to satisfy the non overlapping constrain? > Run LCS for both repaired and unrepaired data > - > > Key: CASSANDRA-8004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8004 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Labels: compaction > Fix For: 2.1.1 > > > If a user has leveled compaction configured, we should run that for both the > unrepaired and the repaired data. I think this would make things a lot easier > for end users > It would simplify migration to incremental repairs as well, if a user runs > incremental repair on its nice leveled unrepaired data, we wont need to drop > it all to L0, instead we can just start moving sstables from the unrepaired > leveling straight into the repaired leveling > Idea could be to have two instances of LeveledCompactionStrategy and move > sstables between the instances after an incremental repair run (and let LCS > be totally oblivious to whether it handles repaired or unrepaired data). Same > should probably apply to any compaction strategy, run two instances and > remove all repaired/unrepaired logic from the strategy itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-6998) HintedHandoff - expired hints may block future hints deliveries
[
https://issues.apache.org/jira/browse/CASSANDRA-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko reassigned CASSANDRA-6998:
Assignee: Aleksey Yeschenko
> HintedHandoff - expired hints may block future hints deliveries
> ---
>
> Key: CASSANDRA-6998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6998
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: - cluster of two DCs: DC1, DC2
> - keyspace using NetworkTopologyStrategy (replication factors for both DCs)
> - heavy load (write:read, 100:1) with LOCAL_QUORUM using Java driver setup
> with DC awareness, writing to DC1
>Reporter: Scooletz
>Assignee: Aleksey Yeschenko
> Labels: HintedHandoff, TTL
> Attachments: 6998
>
>
> For tests purposes, DC2 was shut down for 1 day. The _hints_ table was filled
> with millions of rows. Now, when _HintedHandOffManager_ tries to
> _doDeliverHintsToEndpoint_ it queries the store with
> QueryFilter.getSliceFilter which counts deleted (TTLed) cells and throws
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException.
> Throwing this exception stops the manager from running compaction as it is
> run only after successful handoff. This leaves the HH practically disabled
> till administrator runs truncateAllHints.
> Wouldn't it be nicer if on
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException run compaction?
> That would remove TTLed hints leaving whole HH mechanism in a healthy state.
> The stacktrace is:
> {quote}
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:201)
> 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:1487)
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1306)
> at
> org.apache.cassandra.db.HintedHandOffManager.doDeliverHintsToEndpoint(HintedHandOffManager.java:351)
> at
> org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:309)
> at
> org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:92)
> at
> org.apache.cassandra.db.HintedHandOffManager$4.run(HintedHandOffManager.java:530)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6998) HintedHandoff - expired hints may block future hints deliveries
[
https://issues.apache.org/jira/browse/CASSANDRA-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-6998:
-
Attachment: 6998-v2.txt
> HintedHandoff - expired hints may block future hints deliveries
> ---
>
> Key: CASSANDRA-6998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6998
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: - cluster of two DCs: DC1, DC2
> - keyspace using NetworkTopologyStrategy (replication factors for both DCs)
> - heavy load (write:read, 100:1) with LOCAL_QUORUM using Java driver setup
> with DC awareness, writing to DC1
>Reporter: Scooletz
>Assignee: Aleksey Yeschenko
> Labels: HintedHandoff, TTL
> Attachments: 6998, 6998-v2.txt
>
>
> For tests purposes, DC2 was shut down for 1 day. The _hints_ table was filled
> with millions of rows. Now, when _HintedHandOffManager_ tries to
> _doDeliverHintsToEndpoint_ it queries the store with
> QueryFilter.getSliceFilter which counts deleted (TTLed) cells and throws
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException.
> Throwing this exception stops the manager from running compaction as it is
> run only after successful handoff. This leaves the HH practically disabled
> till administrator runs truncateAllHints.
> Wouldn't it be nicer if on
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException run compaction?
> That would remove TTLed hints leaving whole HH mechanism in a healthy state.
> The stacktrace is:
> {quote}
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:201)
> 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:1487)
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1306)
> at
> org.apache.cassandra.db.HintedHandOffManager.doDeliverHintsToEndpoint(HintedHandOffManager.java:351)
> at
> org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:309)
> at
> org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:92)
> at
> org.apache.cassandra.db.HintedHandOffManager$4.run(HintedHandOffManager.java:530)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8062) IllegalArgumentException passing blob as tuple value element in list
[
https://issues.apache.org/jira/browse/CASSANDRA-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161301#comment-14161301
]
Bill Mitchell commented on CASSANDRA-8062:
--
The basic CQL statement works fine through the CQL Shell. The difference is
that the CQL Shell passes the statement as text, where with the Java driver a
prepared statement was used with bound parameters, so the request should be
passed in a binary format. So I expect the issue is a protocol formatting
issue, on one side or the other.
Using the 2.1 branch I downloaded from github yesterday, I built a later
server, and the failure mode is the same; only the line numbers are slightly
different.
> 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
>
> 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 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.
[jira] [Updated] (CASSANDRA-6998) HintedHandoff - expired hints may block future hints deliveries
[
https://issues.apache.org/jira/browse/CASSANDRA-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-6998:
-
Attachment: (was: 6998-v2.txt)
> HintedHandoff - expired hints may block future hints deliveries
> ---
>
> Key: CASSANDRA-6998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6998
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: - cluster of two DCs: DC1, DC2
> - keyspace using NetworkTopologyStrategy (replication factors for both DCs)
> - heavy load (write:read, 100:1) with LOCAL_QUORUM using Java driver setup
> with DC awareness, writing to DC1
>Reporter: Scooletz
>Assignee: Aleksey Yeschenko
> Labels: HintedHandoff, TTL
> Fix For: 2.0.11, 2.1.1
>
> Attachments: 6998, 6998-v2.txt
>
>
> For tests purposes, DC2 was shut down for 1 day. The _hints_ table was filled
> with millions of rows. Now, when _HintedHandOffManager_ tries to
> _doDeliverHintsToEndpoint_ it queries the store with
> QueryFilter.getSliceFilter which counts deleted (TTLed) cells and throws
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException.
> Throwing this exception stops the manager from running compaction as it is
> run only after successful handoff. This leaves the HH practically disabled
> till administrator runs truncateAllHints.
> Wouldn't it be nicer if on
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException run compaction?
> That would remove TTLed hints leaving whole HH mechanism in a healthy state.
> The stacktrace is:
> {quote}
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:201)
> 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:1487)
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1306)
> at
> org.apache.cassandra.db.HintedHandOffManager.doDeliverHintsToEndpoint(HintedHandOffManager.java:351)
> at
> org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:309)
> at
> org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:92)
> at
> org.apache.cassandra.db.HintedHandOffManager$4.run(HintedHandOffManager.java:530)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6998) HintedHandoff - expired hints may block future hints deliveries
[
https://issues.apache.org/jira/browse/CASSANDRA-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-6998:
-
Attachment: 6998-v2.txt
> HintedHandoff - expired hints may block future hints deliveries
> ---
>
> Key: CASSANDRA-6998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6998
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: - cluster of two DCs: DC1, DC2
> - keyspace using NetworkTopologyStrategy (replication factors for both DCs)
> - heavy load (write:read, 100:1) with LOCAL_QUORUM using Java driver setup
> with DC awareness, writing to DC1
>Reporter: Scooletz
>Assignee: Aleksey Yeschenko
> Labels: HintedHandoff, TTL
> Fix For: 2.0.11, 2.1.1
>
> Attachments: 6998, 6998-v2.txt
>
>
> For tests purposes, DC2 was shut down for 1 day. The _hints_ table was filled
> with millions of rows. Now, when _HintedHandOffManager_ tries to
> _doDeliverHintsToEndpoint_ it queries the store with
> QueryFilter.getSliceFilter which counts deleted (TTLed) cells and throws
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException.
> Throwing this exception stops the manager from running compaction as it is
> run only after successful handoff. This leaves the HH practically disabled
> till administrator runs truncateAllHints.
> Wouldn't it be nicer if on
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException run compaction?
> That would remove TTLed hints leaving whole HH mechanism in a healthy state.
> The stacktrace is:
> {quote}
> org.apache.cassandra.db.filter.TombstoneOverwhelmingException
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:201)
> 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:1487)
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1306)
> at
> org.apache.cassandra.db.HintedHandOffManager.doDeliverHintsToEndpoint(HintedHandOffManager.java:351)
> at
> org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:309)
> at
> org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:92)
> at
> org.apache.cassandra.db.HintedHandOffManager$4.run(HintedHandOffManager.java:530)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8038) A new config option to ignore column tombstones for RR or not
[ https://issues.apache.org/jira/browse/CASSANDRA-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Takenori Sato updated CASSANDRA-8038: - Attachment: CASSANDRA-8038-v2.txt Added a unit test to ColumnFamilyTest. Moved a config lookup from ArrayBackedSortedColumns#maybeAppendColumn() to SliceQueryFilter#collectReducedColumns() for better performance and easier test. This required to add one parameter to ColumnFamily#maybeAppendColumn. > A new config option to ignore column tombstones for RR or not > - > > Key: CASSANDRA-8038 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8038 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Takenori Sato > Fix For: 2.1.1 > > Attachments: CASSANDRA-8038-v2.txt, CASSANDRA-8038.txt > > > CASSANDRA-6117 addressed the death of Cassandra by column tombstones, and > whose fix was to raise an error when reading more tombstones than a > threshold. I think it is an emergency action, rather than a fix. > We have had this issue for long. So I wondered, in the first place, if it is > really necessary to collect non-gc-able tombstones, which could cause > concurrent mode failures, and OOM eventually? > Actually, I was surprised by the fact that Cassandra takes them into > consideration. Rather, I prefer to raise a threshold, and tell Cassandra to > ignore tombstones for digest calculation of RR because a repair is running > regularly. > I guess there are some people like me, but not all. So what about adding a > new configuration option if Cassandra ignores column tombstones for RR or not? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8038) A new config option to ignore column tombstones for RR or not
[ https://issues.apache.org/jira/browse/CASSANDRA-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Takenori Sato updated CASSANDRA-8038: - Attachment: (was: CASSANDRA-8038-v2.txt) > A new config option to ignore column tombstones for RR or not > - > > Key: CASSANDRA-8038 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8038 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Takenori Sato > Fix For: 2.1.1 > > Attachments: CASSANDRA-8038.txt > > > CASSANDRA-6117 addressed the death of Cassandra by column tombstones, and > whose fix was to raise an error when reading more tombstones than a > threshold. I think it is an emergency action, rather than a fix. > We have had this issue for long. So I wondered, in the first place, if it is > really necessary to collect non-gc-able tombstones, which could cause > concurrent mode failures, and OOM eventually? > Actually, I was surprised by the fact that Cassandra takes them into > consideration. Rather, I prefer to raise a threshold, and tell Cassandra to > ignore tombstones for digest calculation of RR because a repair is running > regularly. > I guess there are some people like me, but not all. So what about adding a > new configuration option if Cassandra ignores column tombstones for RR or not? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8038) A new config option to ignore column tombstones for RR or not
[ https://issues.apache.org/jira/browse/CASSANDRA-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Takenori Sato updated CASSANDRA-8038: - Attachment: CASSANDRA-8038-v2.txt > A new config option to ignore column tombstones for RR or not > - > > Key: CASSANDRA-8038 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8038 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Takenori Sato > Fix For: 2.1.1 > > Attachments: CASSANDRA-8038-v2.txt, CASSANDRA-8038.txt > > > CASSANDRA-6117 addressed the death of Cassandra by column tombstones, and > whose fix was to raise an error when reading more tombstones than a > threshold. I think it is an emergency action, rather than a fix. > We have had this issue for long. So I wondered, in the first place, if it is > really necessary to collect non-gc-able tombstones, which could cause > concurrent mode failures, and OOM eventually? > Actually, I was surprised by the fact that Cassandra takes them into > consideration. Rather, I prefer to raise a threshold, and tell Cassandra to > ignore tombstones for digest calculation of RR because a repair is running > regularly. > I guess there are some people like me, but not all. So what about adding a > new configuration option if Cassandra ignores column tombstones for RR or not? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7994) Commit logs on the fly compression
[ https://issues.apache.org/jira/browse/CASSANDRA-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161475#comment-14161475 ] Jason Brown commented on CASSANDRA-7994: [~m0nstermind], what tag or SHA-hash did you rebase on? It will make reviewing this 74k patch a little easier... > Commit logs on the fly compression > --- > > Key: CASSANDRA-7994 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7994 > Project: Cassandra > Issue Type: New Feature >Reporter: Oleg Anastasyev > Attachments: CompressedCommitLogs-7994.txt > > > This patch employs lz4 algo to comress commit logs. This could be useful to > conserve disk space either archiving commit logs for a long time or for > conserviing iops for use cases with often and large mutations updating the > same record. > The compression is performed on blocks of 64k, for better cross mutation > compression. CRC is computed on each 64k block, unlike original code > computing it on each individual mutation. > On one of our real production cluster this saved 2/3 of the space consumed by > commit logs. The replay is 20-30% slower for the same number of mutations. > While doing this, also refactored commit log reading code to CommitLogReader > class, which i believe makes code cleaner. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8004) Run LCS for both repaired and unrepaired data
[ https://issues.apache.org/jira/browse/CASSANDRA-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161494#comment-14161494 ] Marcus Eriksson commented on CASSANDRA-8004: [~kohlisankalp] not initially, what I want to avoid here is the really painful migration to using incremental backups. For the first incremental run, the repaired leveling will be totally empty and we can move sstables over directly. The future incremental repairs will do a "can I move this sstable from unrepaired level X to repaired level X?", and the answer will most often be "nope", then we drop it to level 0. It might be a good idea to consider doing in the future (3.0) though. I'm targeting 2.1 here and want to keep it as simple as possible. > Run LCS for both repaired and unrepaired data > - > > Key: CASSANDRA-8004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8004 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Labels: compaction > Fix For: 2.1.1 > > > If a user has leveled compaction configured, we should run that for both the > unrepaired and the repaired data. I think this would make things a lot easier > for end users > It would simplify migration to incremental repairs as well, if a user runs > incremental repair on its nice leveled unrepaired data, we wont need to drop > it all to L0, instead we can just start moving sstables from the unrepaired > leveling straight into the repaired leveling > Idea could be to have two instances of LeveledCompactionStrategy and move > sstables between the instances after an incremental repair run (and let LCS > be totally oblivious to whether it handles repaired or unrepaired data). Same > should probably apply to any compaction strategy, run two instances and > remove all repaired/unrepaired logic from the strategy itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7994) Commit logs on the fly compression
[ https://issues.apache.org/jira/browse/CASSANDRA-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161516#comment-14161516 ] Oleg Anastasyev commented on CASSANDRA-7994: on this one: d96485ff16d8b90173007a8d6601aba8d105b8f0 > Commit logs on the fly compression > --- > > Key: CASSANDRA-7994 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7994 > Project: Cassandra > Issue Type: New Feature >Reporter: Oleg Anastasyev > Attachments: CompressedCommitLogs-7994.txt > > > This patch employs lz4 algo to comress commit logs. This could be useful to > conserve disk space either archiving commit logs for a long time or for > conserviing iops for use cases with often and large mutations updating the > same record. > The compression is performed on blocks of 64k, for better cross mutation > compression. CRC is computed on each 64k block, unlike original code > computing it on each individual mutation. > On one of our real production cluster this saved 2/3 of the space consumed by > commit logs. The replay is 20-30% slower for the same number of mutations. > While doing this, also refactored commit log reading code to CommitLogReader > class, which i believe makes code cleaner. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7460) Send source sstable level when bootstrapping or replacing nodes
[ https://issues.apache.org/jira/browse/CASSANDRA-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161534#comment-14161534 ] Marcus Eriksson commented on CASSANDRA-7460: rebased and pushed here: https://github.com/krummas/cassandra/commits/marcuse/7460 > Send source sstable level when bootstrapping or replacing nodes > --- > > Key: CASSANDRA-7460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7460 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0 > > Attachments: 0001-wip-keep-sstable-level-when-bootstrapping.patch > > > When replacing or bootstrapping a new node we can keep the source sstable > level to avoid doing alot of compaction after bootstrap -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6455) Improve concurrency of repair process
[ https://issues.apache.org/jira/browse/CASSANDRA-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161539#comment-14161539 ] Marcus Eriksson commented on CASSANDRA-6455: bq. I'm seeing OOM on rebased version What was the reason and fix for this? > Improve concurrency of repair process > - > > Key: CASSANDRA-6455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6455 > Project: Cassandra > Issue Type: Improvement >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Minor > Fix For: 3.0 > > Attachments: 6455-3.0-v2.txt, 6455-3.0.txt, 6455.txt > > > Currently, most of the repair tasks (taking snapshots, send/receiving merkle > tree, compute MT difference, etc) are done on single threaded > AntiEntropyStage. > This causes a problem like CASSANDRA-6415 and likely to cause unnecessary > wait. > Also, repair is done one CF at the time. I think we can parallelize > this(concurrency is configurable by a user based on # of CF and load of the > nodes) for faster processing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8038) A new config option to ignore column tombstones for RR or not
[ https://issues.apache.org/jira/browse/CASSANDRA-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Takenori Sato updated CASSANDRA-8038: - Attachment: CASSANDRA-8038-v3.txt ArrayBackedSortedColumns#maybeAppendColumn didn't work as expected. Improved the unit test, and fixed it. > A new config option to ignore column tombstones for RR or not > - > > Key: CASSANDRA-8038 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8038 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Takenori Sato > Fix For: 2.1.1 > > Attachments: CASSANDRA-8038-v2.txt, CASSANDRA-8038-v3.txt, > CASSANDRA-8038.txt > > > CASSANDRA-6117 addressed the death of Cassandra by column tombstones, and > whose fix was to raise an error when reading more tombstones than a > threshold. I think it is an emergency action, rather than a fix. > We have had this issue for long. So I wondered, in the first place, if it is > really necessary to collect non-gc-able tombstones, which could cause > concurrent mode failures, and OOM eventually? > Actually, I was surprised by the fact that Cassandra takes them into > consideration. Rather, I prefer to raise a threshold, and tell Cassandra to > ignore tombstones for digest calculation of RR because a repair is running > regularly. > I guess there are some people like me, but not all. So what about adding a > new configuration option if Cassandra ignores column tombstones for RR or not? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
