date:20140807

[jira] [Updated] (CASSANDRA-7694) Expected Compaction Interruption is logged as ERROR

2014-08-07 Thread Marcus Eriksson (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-7694:
---

Attachment: 0001-dont-call-super-in-afterExecute.patch

the exception gets logged as ERROR since we call super.afterExecute first in 
CE.afterExecute

attaching patch to remove the super call, looks like we cover all things done 
in DTPE.afterExecute in CE.afterExecute

 Expected Compaction Interruption is logged as ERROR
 ---

 Key: CASSANDRA-7694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7694
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: OSX and Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Marcus Eriksson
Priority: Minor
 Fix For: 2.1.1

 Attachments: 0001-dont-call-super-in-afterExecute.patch, 
 compaction_error.log


 As seen in the attached log, occasionally a major compaction will interrupt 
 other running compactions. This is not an error and is expected behavior. 
 However this is logged at ERROR. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7395) Support for pure user-defined functions (UDF)

2014-08-07 Thread Sylvain Lebresne (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088957#comment-14088957
]

Sylvain Lebresne commented on CASSANDRA-7395:
-

bq. Go ahead and start native_protocol_v4.spec. Function stuff can be v4-only.

Actually, I'd rather left that to a separate ticket if you don't mind: starting
a v4 protocol right now feels a tad premature, I'd rather stick to listing the
reason to create such version first (so create a ticket a tag it 'protocolV4').
I'm fine with not handling any notification in this ticket.

Support for pure user-defined functions (UDF)
-

Key: CASSANDRA-7395
URL: https://issues.apache.org/jira/browse/CASSANDRA-7395
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0

Attachments: 7395-dtest.txt, 7395-native-3-4.txt, 7395.txt,
udf-create-syntax.png, udf-drop-syntax.png

We have some tickets for various aspects of UDF (CASSANDRA-4914,
CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of
ocean-boiling.
Let's start with something simple: allowing pure user-defined functions in
the SELECT clause of a CQL query. That's it.
By pure I mean, must depend only on the input parameters. No side effects.
No exposure to C* internals. Column values in, result out.
http://en.wikipedia.org/wiki/Pure_function

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7694) Expected Compaction Interruption is logged as ERROR

2014-08-07 Thread Marcus Eriksson (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-7694:
---

Attachment: (was: 0001-dont-call-super-in-afterExecute.patch)

 Expected Compaction Interruption is logged as ERROR
 ---

 Key: CASSANDRA-7694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7694
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: OSX and Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Marcus Eriksson
Priority: Minor
 Fix For: 2.1.1

 Attachments: compaction_error.log


 As seen in the attached log, occasionally a major compaction will interrupt 
 other running compactions. This is not an error and is expected behavior. 
 However this is logged at ERROR. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7694) Expected Compaction Interruption is logged as ERROR

2014-08-07 Thread Marcus Eriksson (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088925#comment-14088925
 ] 

Marcus Eriksson edited comment on CASSANDRA-7694 at 8/7/14 8:10 AM:


the exception gets logged as ERROR since we call super.afterExecute first in 
CE.afterExecute

attaching patch to remove the super call


was (Author: krummas):
the exception gets logged as ERROR since we call super.afterExecute first in 
CE.afterExecute

attaching patch to remove the super call, looks like we cover all things done 
in DTPE.afterExecute in CE.afterExecute

 Expected Compaction Interruption is logged as ERROR
 ---

 Key: CASSANDRA-7694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7694
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: OSX and Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Marcus Eriksson
Priority: Minor
 Fix For: 2.1.1

 Attachments: 0001-dont-call-super-in-afterExecute.patch, 
 compaction_error.log


 As seen in the attached log, occasionally a major compaction will interrupt 
 other running compactions. This is not an error and is expected behavior. 
 However this is logged at ERROR. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7694) Expected Compaction Interruption is logged as ERROR

2014-08-07 Thread Marcus Eriksson (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-7694:
---

Attachment: 0001-dont-call-super-in-afterExecute.patch

 Expected Compaction Interruption is logged as ERROR
 ---

 Key: CASSANDRA-7694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7694
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: OSX and Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Marcus Eriksson
Priority: Minor
 Fix For: 2.1.1

 Attachments: 0001-dont-call-super-in-afterExecute.patch, 
 compaction_error.log


 As seen in the attached log, occasionally a major compaction will interrupt 
 other running compactions. This is not an error and is expected behavior. 
 However this is logged at ERROR. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7708) UDF schema change events/results

2014-08-07 Thread Robert Stupp (JIRA)

Robert Stupp created CASSANDRA-7708:
---

 Summary: UDF schema change events/results
 Key: CASSANDRA-7708
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7708
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp


Schema change notifications for UDF might be interesting for client.
This covers both - the result of {{CREATE}} + {{DROP}} statements and events.

Just adding {{FUNCTION}} as a new target for these events breaks previous 
native protocol contract.

Proposal is to introduce a new target {{FUNCTION}} in native protocol v4.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7395) Support for pure user-defined functions (UDF)

2014-08-07 Thread Robert Stupp (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088992#comment-14088992
 ] 

Robert Stupp commented on CASSANDRA-7395:
-

OK - it's CASSANDRA-7708 - I can comment out the changes in 7395 and mark them 
with a {{// TODO CASSANDRA-7708 protocolV4}} if that's ok

 Support for pure user-defined functions (UDF)
 -

 Key: CASSANDRA-7395
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7395
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Robert Stupp
  Labels: cql
 Fix For: 3.0

 Attachments: 7395-dtest.txt, 7395-native-3-4.txt, 7395.txt, 
 udf-create-syntax.png, udf-drop-syntax.png


 We have some tickets for various aspects of UDF (CASSANDRA-4914, 
 CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of 
 ocean-boiling.
 Let's start with something simple: allowing pure user-defined functions in 
 the SELECT clause of a CQL query.  That's it.
 By pure I mean, must depend only on the input parameters.  No side effects. 
  No exposure to C* internals.  Column values in, result out.  
 http://en.wikipedia.org/wiki/Pure_function



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7395) Support for pure user-defined functions (UDF)

2014-08-07 Thread Sylvain Lebresne (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088997#comment-14088997
]

Sylvain Lebresne commented on CASSANDRA-7395:
-

bq. I can comment out the changes in 7395 and mark them with a // TODO
CASSANDRA-7708 protocolV4 if that's ok

Can't you just remove them? The point of making a separate ticket is that we'll
deal with that later. No point in having tons of comment that makes the patch
bigger and may or may not be useful later.

As a side note, for reasonably large patch (and 100K is definitively large),
it would be really nice to try to split work in digestible commits, and ideally
to put them in some git branch somewhere. Makes reviewing (and iteration over
the review) a lot easier.

Support for pure user-defined functions (UDF)
-

Attachments: 7395-dtest.txt, 7395-native-3-4.txt, 7395.txt,
udf-create-syntax.png, udf-drop-syntax.png

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7282) Faster Memtable map

2014-08-07 Thread Benedict (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089019#comment-14089019
 ] 

Benedict commented on CASSANDRA-7282:
-

Just pushed a minor update removing an extraneous comment and making the resize 
threshold triggering uniform + clearer.

Agree it would be good to get some performance numbers on this, but I'm not 
sure which magical facilities you're referring to? New stress isn't likely to 
stress this bit out any more interestingly than old stress, and we don't yet 
have a working magical performance service I don't think...

 Faster Memtable map
 ---

 Key: CASSANDRA-7282
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7282
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Benedict
  Labels: performance
 Fix For: 3.0


 Currently we maintain a ConcurrentSkipLastMap of DecoratedKey - Partition in 
 our memtables. Maintaining this is an O(lg(n)) operation; since the vast 
 majority of users use a hash partitioner, it occurs to me we could maintain a 
 hybrid ordered list / hash map. The list would impose the normal order on the 
 collection, but a hash index would live alongside as part of the same data 
 structure, simply mapping into the list and permitting O(1) lookups and 
 inserts.
 I've chosen to implement this initial version as a linked-list node per item, 
 but we can optimise this in future by storing fatter nodes that permit a 
 cache-line's worth of hashes to be checked at once,  further reducing the 
 constant factor costs for lookups.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7709) sstable2json has resource leaks

2014-08-07 Thread Benjamin Lerer (JIRA)

Benjamin Lerer created CASSANDRA-7709:
-

 Summary: sstable2json has resource leaks
 Key: CASSANDRA-7709
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7709
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
Priority: Minor
 Fix For: 2.0.10


Coverity found 3 resource leak within  SSTable2JsonExporter:
** CID 71971:  Resource leak  (RESOURCE_LEAK)
/src/java/org/apache/cassandra/tools/SSTableExport.java: 300 in
org.apache.cassandra.tools.SSTableExport.export(org.apache.cassandra.io.sstable.Descriptor,
java.io.PrintStream, java.util.Collection, java.lang.String[],
org.apache.cassandra.config.CFMetaData)()

** CID 71972:  Resource leak on an exceptional path  (RESOURCE_LEAK)
/src/java/org/apache/cassandra/tools/SSTableExport.java: 332 in
org.apache.cassandra.tools.SSTableExport.export(org.apache.cassandra.io.sstable.SSTableReader,
java.io.PrintStream, java.lang.String[],
org.apache.cassandra.config.CFMetaData)()

** CID 71975:  Resource leak on an exceptional path  (RESOURCE_LEAK)
/src/java/org/apache/cassandra/tools/SSTableExport.java: 236 in
org.apache.cassandra.tools.SSTableExport.enumeratekeys(org.apache.cassandra.io.sstable.Descriptor,
java.io.PrintStream, org.apache.cassandra.config.CFMetaData)()



*** CID 71971:  Resource leak  (RESOURCE_LEAK)
/src/java/org/apache/cassandra/tools/SSTableExport.java: 300 in
org.apache.cassandra.tools.SSTableExport.export(org.apache.cassandra.io.sstable.Descriptor,
java.io.PrintStream, java.util.Collection, java.lang.String[],
org.apache.cassandra.config.CFMetaData)()
294 i++;
295 serializeRow(deletionInfo, atomIterator,
sstable.metadata, decoratedKey, outs);
296 }
297
298 outs.println(\n]);
299 outs.flush();
 CID 71971:  Resource leak  (RESOURCE_LEAK)
 Variable dfile going out of scope leaks the resource it refers to.
300 }
301
302 // This is necessary to accommodate the test suite since
you cannot open a Reader more
303 // than once from within the same process.
304 static void export(SSTableReader reader, PrintStream outs,
String[] excludes, CFMetaData metadata) throws IOException
305 {


*** CID 71972:  Resource leak on an exceptional path  (RESOURCE_LEAK)
/src/java/org/apache/cassandra/tools/SSTableExport.java: 332 in
org.apache.cassandra.tools.SSTableExport.export(org.apache.cassandra.io.sstable.SSTableReader,
java.io.PrintStream, java.lang.String[],
org.apache.cassandra.config.CFMetaData)()
326 if (excludeSet.contains(currentKey))
327 continue;
328 else if (i != 0)
329 outs.println(,);
330
331 serializeRow(row, row.getKey(), outs);
 CID 71972:  Resource leak on an exceptional path  (RESOURCE_LEAK)
 Variable scanner going out of scope leaks the resource it refers to.
332 checkStream(outs);
333
334 i++;
335 }
336
337 outs.println(\n]);


*** CID 71975:  Resource leak on an exceptional path  (RESOURCE_LEAK)
/src/java/org/apache/cassandra/tools/SSTableExport.java: 236 in
org.apache.cassandra.tools.SSTableExport.enumeratekeys(org.apache.cassandra.io.sstable.Descriptor,
java.io.PrintStream, org.apache.cassandra.config.CFMetaData)()
230 while (iter.hasNext())
231 {
232 DecoratedKey key = iter.next();
233
234 // validate order of the keys in the sstable
235 if (lastKey != null  lastKey.compareTo(key)  0)
 CID 71975:  Resource leak on an exceptional path  (RESOURCE_LEAK)
 Variable iter going out of scope leaks the resource it refers to.
236 throw new IOException(Key out of order!  +
lastKey ++ key);
237 lastKey = key;
238
239
outs.println(metadata.getKeyValidator().getString(key.getKey()));
240 checkStream(outs); // flushes
241 }





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7282) Faster Memtable map

2014-08-07 Thread Aleksey Yeschenko (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089071#comment-14089071
 ] 

Aleksey Yeschenko commented on CASSANDRA-7282:
--

bq. I'm not sure which magical facilities you're referring to

Just Ryan's stress setup (:

 Faster Memtable map
 ---

 Key: CASSANDRA-7282
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7282
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Benedict
  Labels: performance
 Fix For: 3.0


 Currently we maintain a ConcurrentSkipLastMap of DecoratedKey - Partition in 
 our memtables. Maintaining this is an O(lg(n)) operation; since the vast 
 majority of users use a hash partitioner, it occurs to me we could maintain a 
 hybrid ordered list / hash map. The list would impose the normal order on the 
 collection, but a hash index would live alongside as part of the same data 
 structure, simply mapping into the list and permitting O(1) lookups and 
 inserts.
 I've chosen to implement this initial version as a linked-list node per item, 
 but we can optimise this in future by storing fatter nodes that permit a 
 cache-line's worth of hashes to be checked at once,  further reducing the 
 constant factor costs for lookups.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7710) nodetool ring throws exception if run on machine without Cassandra

2014-08-07 Thread JIRA

Jimmy Mårdell created CASSANDRA-7710:


 Summary: nodetool ring throws exception if run on machine without 
Cassandra
 Key: CASSANDRA-7710
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7710
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jimmy Mårdell
Priority: Minor


DatabaseDescriptor.getNumTokens() is invoked in the nodetool ring command which 
doesn't work so well when running on a machine where Cassandra doesnt' exist. 
And it has all kind of side effects as well.

This seems fixed in 2.1 but would be nice if it was fixed in 2.0 as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7711) composite column not sliced when using IN clause on (other) composite columns

2014-08-07 Thread Frens Jan Rumph (JIRA)

Frens Jan Rumph created CASSANDRA-7711:
--

 Summary: composite column not sliced when using IN clause on 
(other) composite columns
 Key: CASSANDRA-7711
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7711
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cassandra 2.0.9
Reporter: Frens Jan Rumph


Hi,

I'm storing data points in cassandra keyed by a number of values and a 
timestamp. I'd want to use IN clauses to select points and sliced by time. The 
in clauses work, but I can't get it to work in combination with the slicing: 
all values are returned / the range in the where clause seems to be ignored.

A dumbed down abstract version of my layout and some sample data:

{code}
create table tbl (
  a text,
  b text,
  c int,
  d int,
  primary key ((a), b, c)
);

insert into tbl (a,b,c,d) values ('a1', 'b1', 1, 1);
insert into tbl (a,b,c,d) values ('a1', 'b1', 2, 2);
insert into tbl (a,b,c,d) values ('a1', 'b2', 1, 1);
insert into tbl (a,b,c,d) values ('a1', 'b2', 2, 2);
insert into tbl (a,b,c,d) values ('a2', 'b1', 1, 1);
insert into tbl (a,b,c,d) values ('a2', 'b1', 2, 2);
insert into tbl (a,b,c,d) values ('a3', 'b2', 1, 1);
insert into tbl (a,b,c,d) values ('a3', 'b2', 2, 2);
{code}

So the table contains:
{code}
 a  | b  | c | d
++---+---
 a1 | b1 | 1 | 1
 a1 | b1 | 2 | 2
 a1 | b2 | 1 | 1
 a1 | b2 | 2 | 2
 a2 | b1 | 1 | 1
 a2 | b1 | 2 | 2
 a3 | b2 | 1 | 1
 a3 | b2 | 2 | 2
{code}


When performing {{select * from tbl where a in ('a1', 'a2') and (b) in (('b1'), 
('b2')) and c  1;}} I get:
{code}
 a  | b  | c | d
++---+---
 a1 | b1 | 1 | 1
 a1 | b1 | 2 | 2
 a1 | b2 | 1 | 1
 a1 | b2 | 2 | 2
 a2 | b1 | 1 | 1
 a2 | b1 | 2 | 2
{code}

But I expected:
{code}
 a  | b  | c | d
++---+---
 a1 | b1 | 2 | 2
 a1 | b2 | 2 | 2
 a2 | b1 | 2 | 2
{code}


Am I doing something wrong? Or is {{c  1}} incorrectly ignored?


{{select * from tbl where a in ('a1', 'a2') and b='b1' and c  1;}} does 
correctly produce:
{code}
a  | b  | c | d
++---+---
 a1 | b1 | 2 | 2
 a2 | b1 | 2 | 2
{code}

So I expect this behaviour to relate to the interworking of the IN clause on 
the clustering column b and the  predicate on column c.

Cheers,
Frens Jan



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7313) SecondaryIndex not deleting column definition

2014-08-07 Thread Sam Tunnicliffe (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089152#comment-14089152
 ] 

Sam Tunnicliffe commented on CASSANDRA-7313:


I don't see a problem with the {{remove()}} method of the iterator obtained 
from columnDefs.iterator, a quick test shows that it does in fact remove from 
the underlying Set when invoked. My theory would be that the issue is actually 
with the equality check between ByteBuffers. 
Adding a unit test would let us verify whether or not the patch actually has 
some effect (I suspect that it doesn't). If that isn't the case I would dig 
into the name comparison.

(n.b. I'm assuming the affects version should be 2.1 here as the patch doesn't 
apply to 2.0)

 SecondaryIndex not deleting column definition
 -

 Key: CASSANDRA-7313
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7313
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Andrés de la Peña
Priority: Minor
  Labels: 2i, columnDefinition, secondaryIndex
 Attachments: dSecondaryIndex-removeColumnDef.diff.txt


 The method _SecondaryIndex#removeColumnDef_ does not delete the requested 
 column definition. I think this may be due to the iterator's remove method:
 {code:java}
 void removeColumnDef(ByteBuffer name)
 {
 IteratorColumnDefinition it = columnDefs.iterator();
 while (it.hasNext())
 {
 if (it.next().name.bytes.equals(name))
 it.remove();
 }
 }
 {code}
 For me it has been problematic when deleting a per row index in a column 
 family and then creating a new one.
 I attach a patch that may solve the problem.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7709) sstable2json has resource leaks

2014-08-07 Thread Benjamin Lerer (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-7709:
--

Attachment: CASSANDRA-7709.txt

 sstable2json has resource leaks
 ---

 Key: CASSANDRA-7709
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7709
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
Priority: Minor
 Fix For: 2.0.10

 Attachments: CASSANDRA-7709.txt


 Coverity found 3 resource leak within  SSTable2JsonExporter:
 ** CID 71971:  Resource leak  (RESOURCE_LEAK)
 /src/java/org/apache/cassandra/tools/SSTableExport.java: 300 in
 org.apache.cassandra.tools.SSTableExport.export(org.apache.cassandra.io.sstable.Descriptor,
 java.io.PrintStream, java.util.Collection, java.lang.String[],
 org.apache.cassandra.config.CFMetaData)()
 ** CID 71972:  Resource leak on an exceptional path  (RESOURCE_LEAK)
 /src/java/org/apache/cassandra/tools/SSTableExport.java: 332 in
 org.apache.cassandra.tools.SSTableExport.export(org.apache.cassandra.io.sstable.SSTableReader,
 java.io.PrintStream, java.lang.String[],
 org.apache.cassandra.config.CFMetaData)()
 ** CID 71975:  Resource leak on an exceptional path  (RESOURCE_LEAK)
 /src/java/org/apache/cassandra/tools/SSTableExport.java: 236 in
 org.apache.cassandra.tools.SSTableExport.enumeratekeys(org.apache.cassandra.io.sstable.Descriptor,
 java.io.PrintStream, org.apache.cassandra.config.CFMetaData)()
 
 *** CID 71971:  Resource leak  (RESOURCE_LEAK)
 /src/java/org/apache/cassandra/tools/SSTableExport.java: 300 in
 org.apache.cassandra.tools.SSTableExport.export(org.apache.cassandra.io.sstable.Descriptor,
 java.io.PrintStream, java.util.Collection, java.lang.String[],
 org.apache.cassandra.config.CFMetaData)()
 294 i++;
 295 serializeRow(deletionInfo, atomIterator,
 sstable.metadata, decoratedKey, outs);
 296 }
 297
 298 outs.println(\n]);
 299 outs.flush();
  CID 71971:  Resource leak  (RESOURCE_LEAK)
  Variable dfile going out of scope leaks the resource it refers to.
 300 }
 301
 302 // This is necessary to accommodate the test suite since
 you cannot open a Reader more
 303 // than once from within the same process.
 304 static void export(SSTableReader reader, PrintStream outs,
 String[] excludes, CFMetaData metadata) throws IOException
 305 {
 
 *** CID 71972:  Resource leak on an exceptional path  (RESOURCE_LEAK)
 /src/java/org/apache/cassandra/tools/SSTableExport.java: 332 in
 org.apache.cassandra.tools.SSTableExport.export(org.apache.cassandra.io.sstable.SSTableReader,
 java.io.PrintStream, java.lang.String[],
 org.apache.cassandra.config.CFMetaData)()
 326 if (excludeSet.contains(currentKey))
 327 continue;
 328 else if (i != 0)
 329 outs.println(,);
 330
 331 serializeRow(row, row.getKey(), outs);
  CID 71972:  Resource leak on an exceptional path  (RESOURCE_LEAK)
  Variable scanner going out of scope leaks the resource it refers to.
 332 checkStream(outs);
 333
 334 i++;
 335 }
 336
 337 outs.println(\n]);
 
 *** CID 71975:  Resource leak on an exceptional path  (RESOURCE_LEAK)
 /src/java/org/apache/cassandra/tools/SSTableExport.java: 236 in
 org.apache.cassandra.tools.SSTableExport.enumeratekeys(org.apache.cassandra.io.sstable.Descriptor,
 java.io.PrintStream, org.apache.cassandra.config.CFMetaData)()
 230 while (iter.hasNext())
 231 {
 232 DecoratedKey key = iter.next();
 233
 234 // validate order of the keys in the sstable
 235 if (lastKey != null  lastKey.compareTo(key)  0)
  CID 71975:  Resource leak on an exceptional path  (RESOURCE_LEAK)
  Variable iter going out of scope leaks the resource it refers to.
 236 throw new IOException(Key out of order!  +
 lastKey ++ key);
 237 lastKey = key;
 238
 239
 outs.println(metadata.getKeyValidator().getString(key.getKey()));
 240 checkStream(outs); // flushes
 241 }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[Cassandra Wiki] Update of ContributorsGroup by DaveBrosius

2014-08-07 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The ContributorsGroup page has been changed by DaveBrosius:
https://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=34rev2=35

   * woolfel
   * MichaelShuler
   * BenedictElliottSmith
+  * RobertStupp

[jira] [Commented] (CASSANDRA-7384) Collect metrics on queries by consistency level

2014-08-07 Thread Or Sher (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089234#comment-14089234
]

Or Sher commented on CASSANDRA-7384:

I would be happy to have such metrics, I would even sample count and latency
per column family and per CL.
We have many applications using the same shared clusters.
Many developers from different teams are working with different APIs (Hector
CQL3), and with different standards and wrappers.
As the DBA, I'm not able to verify that each project is using the CL it thinks
or need to. That would really help me out and I'm sure it also help many other
companies where the administration and development have different owners.
Comparing the read/write latency for different CL on run time in our production
cluster would also be a great value.

Collect metrics on queries by consistency level
---

Key: CASSANDRA-7384
URL: https://issues.apache.org/jira/browse/CASSANDRA-7384
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Vishy Kasar
Assignee: sankalp kohli
Priority: Minor
Fix For: 2.0.10

We had cases where cassandra client users thought that they were doing
queries at one consistency level but turned out to be not correct. It will be
good to collect metrics on number of queries done at various consistency
level on the server. See the equivalent JIRA on java driver:
https://datastax-oss.atlassian.net/browse/JAVA-354

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7700) Unexpected exception in RangeTombstoneList.insertFrom during Python Driver Duration Test

2014-08-07 Thread Sylvain Lebresne (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-7700:


Attachment: 7700.txt

 Unexpected exception in RangeTombstoneList.insertFrom during Python Driver 
 Duration Test
 

 Key: CASSANDRA-7700
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7700
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu via ctool. Linux ip-10-199-0-152 3.2.0-57-virtual 
 #87-Ubuntu SMP Tue Nov 12 21:53:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Rick Smith
Assignee: Sylvain Lebresne
 Fix For: 2.0.10

 Attachments: 7700.txt, Tombstone_Exception.txt


 Found the attached exception (duration test log and associated Cassandra log) 
 when running the Python driver duration tests against 
 CASSANDRA_VERSION=cassandra-2.1.0-rc5 and master branch of driver. Error 
 repeated in logs twice over 12 hours on master_gevent cluster, and once on 
 gevent cluster over the same time period. Cluster and associated cluster 
 setup via ctool.
 Log excerpt:
 INFO  [MemtableFlushWriter:184] 2014-08-05 05:45:39,161 Memtable.java:360 - 
 Completed flushing 
 /srv/performance/cass/data/duration_test/ints-133f8c901c2f11e491e66b1b73f81641/duration_test-ints-ka-173-Data.db
  (2131716 bytes) for commitlog position 
 ReplayPosition(segmentId=1407193910537, position=13460548)
 ERROR [SharedPool-Worker-7] 2014-08-05 05:45:45,160 ErrorMessage.java:218 - 
 Unexpected exception during request
 java.lang.AssertionError: null
   at 
 org.apache.cassandra.db.RangeTombstoneList.insertFrom(RangeTombstoneList.java:528)
  ~[main/:na]
   at 
 org.apache.cassandra.db.RangeTombstoneList.addAll(RangeTombstoneList.java:221)
  ~[main/:na]
 more details in attachment.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7700) Unexpected exception in RangeTombstoneList.insertFrom during Python Driver Duration Test

2014-08-07 Thread Sylvain Lebresne (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-7700:


Fix Version/s: (was: 2.1.0)

 Unexpected exception in RangeTombstoneList.insertFrom during Python Driver 
 Duration Test
 

 Key: CASSANDRA-7700
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7700
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu via ctool. Linux ip-10-199-0-152 3.2.0-57-virtual 
 #87-Ubuntu SMP Tue Nov 12 21:53:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Rick Smith
Assignee: Sylvain Lebresne
 Fix For: 2.0.10

 Attachments: 7700.txt, Tombstone_Exception.txt


 Found the attached exception (duration test log and associated Cassandra log) 
 when running the Python driver duration tests against 
 CASSANDRA_VERSION=cassandra-2.1.0-rc5 and master branch of driver. Error 
 repeated in logs twice over 12 hours on master_gevent cluster, and once on 
 gevent cluster over the same time period. Cluster and associated cluster 
 setup via ctool.
 Log excerpt:
 INFO  [MemtableFlushWriter:184] 2014-08-05 05:45:39,161 Memtable.java:360 - 
 Completed flushing 
 /srv/performance/cass/data/duration_test/ints-133f8c901c2f11e491e66b1b73f81641/duration_test-ints-ka-173-Data.db
  (2131716 bytes) for commitlog position 
 ReplayPosition(segmentId=1407193910537, position=13460548)
 ERROR [SharedPool-Worker-7] 2014-08-05 05:45:45,160 ErrorMessage.java:218 - 
 Unexpected exception during request
 java.lang.AssertionError: null
   at 
 org.apache.cassandra.db.RangeTombstoneList.insertFrom(RangeTombstoneList.java:528)
  ~[main/:na]
   at 
 org.apache.cassandra.db.RangeTombstoneList.addAll(RangeTombstoneList.java:221)
  ~[main/:na]
 more details in attachment.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7384) Collect metrics on queries by consistency level

2014-08-07 Thread Or Sher (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089234#comment-14089234
]

Or Sher edited comment on CASSANDRA-7384 at 8/7/14 1:58 PM:

I would be happy to have such metrics, I would even sample count and latency
per column family and per CL.
We have many applications using the same shared clusters.
Many developers from different teams are working with different APIs (Hector
CQL3), and with different standards and wrappers.
As the DBA, I'm not able to verify that each project is using the CL it thinks
or need to use. That would really help me out and I'm sure it also help many
other companies where the administration and development have different owners.
Comparing the read/write latency for different CL on run time in our production
cluster would also be a great value.

was (Author: or.sher1):
I would be happy to have such metrics, I would even sample count and latency
per column family and per CL.
We have many applications using the same shared clusters.
Many developers from different teams are working with different APIs (Hector
CQL3), and with different standards and wrappers.
As the DBA, I'm not able to verify that each project is using the CL it thinks
or need to. That would really help me out and I'm sure it also help many other
companies where the administration and development have different owners.
Comparing the read/write latency for different CL on run time in our production
cluster would also be a great value.

Collect metrics on queries by consistency level
---

--
This message was sent by Atlassian JIRA
(v6.2#6252)

1 2 >

1 - 100 of 172 matches

Mail list logo