[jira] [Updated] (CASSANDRA-5483) Repair tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyuben Todorov updated CASSANDRA-5483: -- Attachment: prerepair-vs-postbuggedrepair.diff The new set of patches (v8.11 to v8.15) cause high cpu usage which doesn't dissipate. This happens on the node on which the repair was issued. To reproduce just apply the patches to [the branch|https://github.com/lyubent/cassandra/tree/5483] and carry out repair using -tr on all 3 nodes. Sometimes this happens on the 1st repair sometimes it takes repairing all 3 nodes multiple times (most it's ever taken me is 6x repairs, 2 on each node in a 3 node ccm cluster). Looking at the threading, there are a lot of _ReadStage_ threads running after this happens (approx 32 that are waiting and 1 that is running) so as far as I can tell the polling doesn't stop even though the repair completed and there is also one TracingStage that is waiting to complete. I'm attaching prerepair-vs-postrepair.diff that shows the extra threads once this problem occurs. Repair tracing -- Key: CASSANDRA-5483 URL: https://issues.apache.org/jira/browse/CASSANDRA-5483 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Yuki Morishita Assignee: Ben Chan Priority: Minor Labels: repair Attachments: 5483-full-trunk.txt, 5483-v06-04-Allow-tracing-ttl-to-be-configured.patch, 5483-v06-05-Add-a-command-column-to-system_traces.events.patch, 5483-v06-06-Fix-interruption-in-tracestate-propagation.patch, 5483-v07-07-Better-constructor-parameters-for-DebuggableThreadPoolExecutor.patch, 5483-v07-08-Fix-brace-style.patch, 5483-v07-09-Add-trace-option-to-a-more-complete-set-of-repair-functions.patch, 5483-v07-10-Correct-name-of-boolean-repairedAt-to-fullRepair.patch, 5483-v08-11-Shorten-trace-messages.-Use-Tracing-begin.patch, 5483-v08-12-Trace-streaming-in-Differencer-StreamingRepairTask.patch, 5483-v08-13-sendNotification-of-local-traces-back-to-nodetool.patch, 5483-v08-14-Poll-system_traces.events.patch, 5483-v08-15-Limit-trace-notifications.-Add-exponential-backoff.patch, ccm-repair-test, cqlsh-left-justify-text-columns.patch, prerepair-vs-postbuggedrepair.diff, test-5483-system_traces-events.txt, trunk@4620823-5483-v02-0001-Trace-filtering-and-tracestate-propagation.patch, trunk@4620823-5483-v02-0002-Put-a-few-traces-parallel-to-the-repair-logging.patch, tr...@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt, tr...@8ebeee1-5483-v01-002-simple-repair-tracing.txt, v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch, v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch, v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.patch I think it would be nice to log repair stats and results like query tracing stores traces to system keyspace. With it, you don't have to lookup each log file to see what was the status and how it performed the repair you invoked. Instead, you can query the repair log with session ID to see the state and stats of all nodes involved in that repair session. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6880) counters++ lock on cells, not partitions
[ https://issues.apache.org/jira/browse/CASSANDRA-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13954712#comment-13954712 ] Aleksey Yeschenko commented on CASSANDRA-6880: -- Force pushed to the same branch, switching stripes from per-cf to global 1024 * concurrent writers. This time for review. counters++ lock on cells, not partitions Key: CASSANDRA-6880 URL: https://issues.apache.org/jira/browse/CASSANDRA-6880 Project: Cassandra Issue Type: Improvement Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Fix For: 2.1 beta2 I'm starting to think that we should switch to locking by cells, not by partitions, when updating counters. With the current 2.1 counters, if nothing changes, the new recommendation would become use smaller partitions, batch updates to the same partition, and that goes against what we usually recommend: 1. Prefer wide partitions to narrow partitions 2. Don't batch counter updates (because you risk to exaggerate undercounting/overcounting in case of a timeout) Locking on cells would cause C* to have to grab more locks for batch counter updates, but would give us generally more predictable performance (independent of partition wideness), and won't force people to remodel their data model if they have often concurrently-updated counters in the same few wide partitions. (It's a small change, code-wise) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-5483) Repair tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Chan updated CASSANDRA-5483: Attachment: 5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch Repair tracing -- Key: CASSANDRA-5483 URL: https://issues.apache.org/jira/browse/CASSANDRA-5483 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Yuki Morishita Assignee: Ben Chan Priority: Minor Labels: repair Attachments: 5483-full-trunk.txt, 5483-v06-04-Allow-tracing-ttl-to-be-configured.patch, 5483-v06-05-Add-a-command-column-to-system_traces.events.patch, 5483-v06-06-Fix-interruption-in-tracestate-propagation.patch, 5483-v07-07-Better-constructor-parameters-for-DebuggableThreadPoolExecutor.patch, 5483-v07-08-Fix-brace-style.patch, 5483-v07-09-Add-trace-option-to-a-more-complete-set-of-repair-functions.patch, 5483-v07-10-Correct-name-of-boolean-repairedAt-to-fullRepair.patch, 5483-v08-11-Shorten-trace-messages.-Use-Tracing-begin.patch, 5483-v08-12-Trace-streaming-in-Differencer-StreamingRepairTask.patch, 5483-v08-13-sendNotification-of-local-traces-back-to-nodetool.patch, 5483-v08-14-Poll-system_traces.events.patch, 5483-v08-15-Limit-trace-notifications.-Add-exponential-backoff.patch, 5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch, ccm-repair-test, cqlsh-left-justify-text-columns.patch, prerepair-vs-postbuggedrepair.diff, test-5483-system_traces-events.txt, trunk@4620823-5483-v02-0001-Trace-filtering-and-tracestate-propagation.patch, trunk@4620823-5483-v02-0002-Put-a-few-traces-parallel-to-the-repair-logging.patch, tr...@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt, tr...@8ebeee1-5483-v01-002-simple-repair-tracing.txt, v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch, v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch, v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.patch I think it would be nice to log repair stats and results like query tracing stores traces to system keyspace. With it, you don't have to lookup each log file to see what was the status and how it performed the repair you invoked. Instead, you can query the repair log with session ID to see the state and stats of all nodes involved in that repair session. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6553) Benchmark counter improvements (counters++)
[ https://issues.apache.org/jira/browse/CASSANDRA-6553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13954743#comment-13954743 ] Aleksey Yeschenko commented on CASSANDRA-6553: -- Could be that 6880 in its previous iteration wasn't name-spacing cells by partition key when calling bulkGet(), and since the cell name is the same in these runs.. yeah, most likely that. Fixed in the latest CASSANDRA-6880 iteration. Benchmark counter improvements (counters++) --- Key: CASSANDRA-6553 URL: https://issues.apache.org/jira/browse/CASSANDRA-6553 Project: Cassandra Issue Type: Test Reporter: Ryan McGuire Assignee: Russ Hatch Fix For: 2.1 beta2 Attachments: 6553.txt, 6553.uber.quorum.bdplab.read.png, 6553.uber.quorum.bdplab.write.png, high_cl_one.png, high_cl_quorum.png, low_cl_one.png, low_cl_quorum.png, tracing.txt, uber_cl_one.png, uber_cl_quorum.png Benchmark the difference in performance between CASSANDRA-6504 and trunk. * Updating totally unrelated counters (different partitions) * Updating the same counters a lot (same cells in the same partition) * Different cells in the same few partitions (hot counter partition) benchmark: https://github.com/apache/cassandra/tree/1218bcacba7edefaf56cf8440d0aea5794c89a1e (old counters) compared to: https://github.com/apache/cassandra/tree/714c423360c36da2a2b365efaf9c5c4f623ed133 (new counters) So far, the above changes should only affect the write path. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-5483) Repair tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Chan updated CASSANDRA-5483: Attachment: (was: 5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch) Repair tracing -- Key: CASSANDRA-5483 URL: https://issues.apache.org/jira/browse/CASSANDRA-5483 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Yuki Morishita Assignee: Ben Chan Priority: Minor Labels: repair Attachments: 5483-full-trunk.txt, 5483-v06-04-Allow-tracing-ttl-to-be-configured.patch, 5483-v06-05-Add-a-command-column-to-system_traces.events.patch, 5483-v06-06-Fix-interruption-in-tracestate-propagation.patch, 5483-v07-07-Better-constructor-parameters-for-DebuggableThreadPoolExecutor.patch, 5483-v07-08-Fix-brace-style.patch, 5483-v07-09-Add-trace-option-to-a-more-complete-set-of-repair-functions.patch, 5483-v07-10-Correct-name-of-boolean-repairedAt-to-fullRepair.patch, 5483-v08-11-Shorten-trace-messages.-Use-Tracing-begin.patch, 5483-v08-12-Trace-streaming-in-Differencer-StreamingRepairTask.patch, 5483-v08-13-sendNotification-of-local-traces-back-to-nodetool.patch, 5483-v08-14-Poll-system_traces.events.patch, 5483-v08-15-Limit-trace-notifications.-Add-exponential-backoff.patch, ccm-repair-test, cqlsh-left-justify-text-columns.patch, prerepair-vs-postbuggedrepair.diff, test-5483-system_traces-events.txt, trunk@4620823-5483-v02-0001-Trace-filtering-and-tracestate-propagation.patch, trunk@4620823-5483-v02-0002-Put-a-few-traces-parallel-to-the-repair-logging.patch, tr...@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt, tr...@8ebeee1-5483-v01-002-simple-repair-tracing.txt, v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch, v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch, v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.patch I think it would be nice to log repair stats and results like query tracing stores traces to system keyspace. With it, you don't have to lookup each log file to see what was the status and how it performed the repair you invoked. Instead, you can query the repair log with session ID to see the state and stats of all nodes involved in that repair session. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-5483) Repair tracing
[
https://issues.apache.org/jira/browse/CASSANDRA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13954746#comment-13954746
]
Ben Chan commented on CASSANDRA-5483:
-
Ouch. After running a before and after test, I'm 99% sure this was the problem.
There was some obviously wrong code in {{waitActivity}} (an older version used
0 instead of -1 to signify done; I apparently forgot to update everything
when I changed this).
Sorry about removing the previous patch. It didn't have the correct {{git diff
-p}} parameters.
For convenience:
{noformat}
W=https://issues.apache.org/jira/secure/attachment
for url in \
$W/12637720/5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch
do [ -e $(basename $url) ] || curl -sO $url; done
git apply 5483-v09-*.patch
ant clean ant
{noformat}
Here's what I used to test with; I get slower and slower repairs, with a hang
on the 5th repair with the before code, and consistent 10-second repairs with
the after code.
{noformat}
cat ccm-nodetool E
#!/bin/sh
# ccm doesn't let us call nodetool with options, but we still need to get the
# host and port config from it.
read -r JMXGET E
/jmx_port/{p=\$2;} \
/binary/{split(\$2,a,/\047/);h=a[2];} \
END{printf(bin/nodetool -h %s -p %s\n,h,p,cmd);}
E
NODETOOL=$(ccm $1 show | awk -F= $JMXGET)
shift
$NODETOOL $@
E
chmod +x ccm-nodetool
for x in $(seq 3); do
for y in $(seq 2); do
echo repair node$x \#$y
./ccm-nodetool node$x repair -tr
done
done
{noformat}
Repair tracing
--
Key: CASSANDRA-5483
URL: https://issues.apache.org/jira/browse/CASSANDRA-5483
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Yuki Morishita
Assignee: Ben Chan
Priority: Minor
Labels: repair
Attachments: 5483-full-trunk.txt,
5483-v06-04-Allow-tracing-ttl-to-be-configured.patch,
5483-v06-05-Add-a-command-column-to-system_traces.events.patch,
5483-v06-06-Fix-interruption-in-tracestate-propagation.patch,
5483-v07-07-Better-constructor-parameters-for-DebuggableThreadPoolExecutor.patch,
5483-v07-08-Fix-brace-style.patch,
5483-v07-09-Add-trace-option-to-a-more-complete-set-of-repair-functions.patch,
5483-v07-10-Correct-name-of-boolean-repairedAt-to-fullRepair.patch,
5483-v08-11-Shorten-trace-messages.-Use-Tracing-begin.patch,
5483-v08-12-Trace-streaming-in-Differencer-StreamingRepairTask.patch,
5483-v08-13-sendNotification-of-local-traces-back-to-nodetool.patch,
5483-v08-14-Poll-system_traces.events.patch,
5483-v08-15-Limit-trace-notifications.-Add-exponential-backoff.patch,
5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch, ccm-repair-test,
cqlsh-left-justify-text-columns.patch, prerepair-vs-postbuggedrepair.diff,
test-5483-system_traces-events.txt,
trunk@4620823-5483-v02-0001-Trace-filtering-and-tracestate-propagation.patch,
trunk@4620823-5483-v02-0002-Put-a-few-traces-parallel-to-the-repair-logging.patch,
tr...@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt,
tr...@8ebeee1-5483-v01-002-simple-repair-tracing.txt,
v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch,
v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch,
v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.patch
I think it would be nice to log repair stats and results like query tracing
stores traces to system keyspace. With it, you don't have to lookup each log
file to see what was the status and how it performed the repair you invoked.
Instead, you can query the repair log with session ID to see the state and
stats of all nodes involved in that repair session.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-5483) Repair tracing
[
https://issues.apache.org/jira/browse/CASSANDRA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13954746#comment-13954746
]
Ben Chan edited comment on CASSANDRA-5483 at 3/30/14 5:24 PM:
--
Ouch. After running a before and after test, I'm 99% sure this was the problem.
There was some obviously wrong code in {{waitActivity}} (an older version used
0 instead of -1 to signify done; I apparently forgot to update everything
when I changed this).
Sorry about removing the previous patch. It didn't have the correct {{git diff
-p}} parameters.
For convenience:
{noformat}
W=https://issues.apache.org/jira/secure/attachment
for url in \
$W/12637720/5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch
do [ -e $(basename $url) ] || curl -sO $url; done
git apply 5483-v09-*.patch
ant clean ant
{noformat}
Here's what I used to test with; I get slower and slower repairs, with a hang
on the 5th repair with the before code, and consistent 10-second repairs with
the after code.
{noformat}
cat ccm-nodetool EE
#!/bin/sh
# ccm doesn't let us call nodetool with options, but we still need to get the
# host and port config from it.
read -r JMXGET E
/jmx_port/{p=\$2;} \
/binary/{split(\$2,a,/\047/);h=a[2];} \
END{printf(bin/nodetool -h %s -p %s\n,h,p);}
E
NODETOOL=$(ccm $1 show | awk -F= $JMXGET)
shift
$NODETOOL $@
EE
chmod +x ccm-nodetool
for x in $(seq 3); do
for y in $(seq 2); do
echo repair node$x \#$y
./ccm-nodetool node$x repair -tr
done
done
{noformat}
edit: minor awk code cleanup, properly nest heredocs.
was (Author: usrbincc):
Ouch. After running a before and after test, I'm 99% sure this was the problem.
There was some obviously wrong code in {{waitActivity}} (an older version used
0 instead of -1 to signify done; I apparently forgot to update everything
when I changed this).
Sorry about removing the previous patch. It didn't have the correct {{git diff
-p}} parameters.
For convenience:
{noformat}
W=https://issues.apache.org/jira/secure/attachment
for url in \
$W/12637720/5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch
do [ -e $(basename $url) ] || curl -sO $url; done
git apply 5483-v09-*.patch
ant clean ant
{noformat}
Here's what I used to test with; I get slower and slower repairs, with a hang
on the 5th repair with the before code, and consistent 10-second repairs with
the after code.
{noformat}
cat ccm-nodetool E
#!/bin/sh
# ccm doesn't let us call nodetool with options, but we still need to get the
# host and port config from it.
read -r JMXGET E
/jmx_port/{p=\$2;} \
/binary/{split(\$2,a,/\047/);h=a[2];} \
END{printf(bin/nodetool -h %s -p %s\n,h,p,cmd);}
E
NODETOOL=$(ccm $1 show | awk -F= $JMXGET)
shift
$NODETOOL $@
E
chmod +x ccm-nodetool
for x in $(seq 3); do
for y in $(seq 2); do
echo repair node$x \#$y
./ccm-nodetool node$x repair -tr
done
done
{noformat}
Repair tracing
--
Key: CASSANDRA-5483
URL: https://issues.apache.org/jira/browse/CASSANDRA-5483
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Yuki Morishita
Assignee: Ben Chan
Priority: Minor
Labels: repair
Attachments: 5483-full-trunk.txt,
5483-v06-04-Allow-tracing-ttl-to-be-configured.patch,
5483-v06-05-Add-a-command-column-to-system_traces.events.patch,
5483-v06-06-Fix-interruption-in-tracestate-propagation.patch,
5483-v07-07-Better-constructor-parameters-for-DebuggableThreadPoolExecutor.patch,
5483-v07-08-Fix-brace-style.patch,
5483-v07-09-Add-trace-option-to-a-more-complete-set-of-repair-functions.patch,
5483-v07-10-Correct-name-of-boolean-repairedAt-to-fullRepair.patch,
5483-v08-11-Shorten-trace-messages.-Use-Tracing-begin.patch,
5483-v08-12-Trace-streaming-in-Differencer-StreamingRepairTask.patch,
5483-v08-13-sendNotification-of-local-traces-back-to-nodetool.patch,
5483-v08-14-Poll-system_traces.events.patch,
5483-v08-15-Limit-trace-notifications.-Add-exponential-backoff.patch,
5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch, ccm-repair-test,
cqlsh-left-justify-text-columns.patch, prerepair-vs-postbuggedrepair.diff,
test-5483-system_traces-events.txt,
trunk@4620823-5483-v02-0001-Trace-filtering-and-tracestate-propagation.patch,
trunk@4620823-5483-v02-0002-Put-a-few-traces-parallel-to-the-repair-logging.patch,
tr...@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt,
tr...@8ebeee1-5483-v01-002-simple-repair-tracing.txt,
v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch,
v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch,
v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.patch
I think it would be nice to log repair stats and results like query tracing
[jira] [Commented] (CASSANDRA-6892) Cassandra 2.0.x validates Thrift columns incorrectly and causes InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13954862#comment-13954862
]
Christian Spriegel commented on CASSANDRA-6892:
---
[~thobbs]: I ran my tests with your patch. Works fine for me.
Cassandra 2.0.x validates Thrift columns incorrectly and causes
InvalidRequestException
---
Key: CASSANDRA-6892
URL: https://issues.apache.org/jira/browse/CASSANDRA-6892
Project: Cassandra
Issue Type: Bug
Components: API
Reporter: Christian Spriegel
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 2.0.7
Attachments: 6892-2.0.txt, CASSANDRA-6892_V1.patch
I just upgrade my local dev machine to Cassandra 2.0, which causes one of my
automated tests to fail now. With the latest 1.2.x it was working fine.
The Exception I get on my client (using Hector) is:
{code}
me.prettyprint.hector.api.exceptions.HInvalidRequestException:
InvalidRequestException(why:(Expected 8 or 0 byte long (21))
[MDS_0][MasterdataIndex][key2] failed validation)
at
me.prettyprint.cassandra.service.ExceptionsTranslatorImpl.translate(ExceptionsTranslatorImpl.java:52)
at
me.prettyprint.cassandra.connection.HConnectionManager.operateWithFailover(HConnectionManager.java:265)
at
me.prettyprint.cassandra.model.ExecutingKeyspace.doExecuteOperation(ExecutingKeyspace.java:113)
at
me.prettyprint.cassandra.model.MutatorImpl.execute(MutatorImpl.java:243)
at
me.prettyprint.cassandra.service.template.AbstractColumnFamilyTemplate.executeBatch(AbstractColumnFamilyTemplate.java:115)
at
me.prettyprint.cassandra.service.template.AbstractColumnFamilyTemplate.executeIfNotBatched(AbstractColumnFamilyTemplate.java:163)
at
me.prettyprint.cassandra.service.template.ColumnFamilyTemplate.update(ColumnFamilyTemplate.java:69)
at
com.mycompany.spring3utils.dataaccess.cassandra.AbstractCassandraDAO.doUpdate(AbstractCassandraDAO.java:482)
Caused by: InvalidRequestException(why:(Expected 8 or 0 byte long (21))
[MDS_0][MasterdataIndex][key2] failed validation)
at
org.apache.cassandra.thrift.Cassandra$batch_mutate_result.read(Cassandra.java:20833)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_batch_mutate(Cassandra.java:964)
at
org.apache.cassandra.thrift.Cassandra$Client.batch_mutate(Cassandra.java:950)
at
me.prettyprint.cassandra.model.MutatorImpl$3.execute(MutatorImpl.java:246)
at
me.prettyprint.cassandra.model.MutatorImpl$3.execute(MutatorImpl.java:1)
at
me.prettyprint.cassandra.service.Operation.executeAndSetResult(Operation.java:104)
at
me.prettyprint.cassandra.connection.HConnectionManager.operateWithFailover(HConnectionManager.java:258)
... 46 more
{code}
The schema of my column family is:
{code}
create column family MasterdataIndex with
compression_options = {sstable_compression:SnappyCompressor,
chunk_length_kb:64} and
comparator = UTF8Type and
key_validation_class = 'CompositeType(UTF8Type,LongType)' and
default_validation_class = BytesType;
{code}
From the error message it looks like Cassandra is trying to validate the
value with the key-validator! (My value in this case it 21 bytes long)
I studied the Cassandra 2.0 code and found something wrong. It seems in
CFMetaData.addDefaultKeyAliases it passes the KeyValidator into
ColumnDefinition.partitionKeyDef. Inside ColumnDefinition the validator is
expected to be the value validator!
In CFMetaData:
{code}
private ListColumnDefinition
addDefaultKeyAliases(ListColumnDefinition pkCols)
{
for (int i = 0; i pkCols.size(); i++)
{
if (pkCols.get(i) == null)
{
Integer idx = null;
AbstractType? type = keyValidator;
if (keyValidator instanceof CompositeType)
{
idx = i;
type = ((CompositeType)keyValidator).types.get(i);
}
// For compatibility sake, we call the first alias 'key'
rather than 'key1'. This
// is inconsistent with column alias, but it's probably not
worth risking breaking compatibility now.
ByteBuffer name = ByteBufferUtil.bytes(i == 0 ?
DEFAULT_KEY_ALIAS : DEFAULT_KEY_ALIAS + (i + 1));
ColumnDefinition newDef =
ColumnDefinition.partitionKeyDef(name, type, idx); // type is LongType in my
case, as it uses keyValidator !!!
column_metadata.put(newDef.name, newDef);
pkCols.set(i, newDef);
[jira] [Assigned] (CASSANDRA-6106) QueryState.getTimestamp() FBUtilities.timestampMicros() reads current timestamp with System.currentTimeMillis() * 1000 instead of System.nanoTime() / 1000
[ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-6106: - Assignee: Benedict Thanks, Chris. I don't think I'm ready to cross the custom JNI code rubicon yet. Let's try gettimeofday or clock_gettime like Blair suggested and see if that's acceptable first. QueryState.getTimestamp() FBUtilities.timestampMicros() reads current timestamp with System.currentTimeMillis() * 1000 instead of System.nanoTime() / 1000 Key: CASSANDRA-6106 URL: https://issues.apache.org/jira/browse/CASSANDRA-6106 Project: Cassandra Issue Type: Improvement Components: Core Environment: DSE Cassandra 3.1, but also HEAD Reporter: Christopher Smith Assignee: Benedict Priority: Minor Labels: timestamps Fix For: 2.1 beta2 Attachments: microtimstamp.patch, microtimstamp_random.patch, microtimstamp_random_rev2.patch I noticed this blog post: http://aphyr.com/posts/294-call-me-maybe-cassandra mentioned issues with millisecond rounding in timestamps and was able to reproduce the issue. If I specify a timestamp in a mutating query, I get microsecond precision, but if I don't, I get timestamps rounded to the nearest millisecond, at least for my first query on a given connection, which substantially increases the possibilities of collision. I believe I found the offending code, though I am by no means sure this is comprehensive. I think we probably need a fairly comprehensive replacement of all uses of System.currentTimeMillis() with System.nanoTime(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-6954) Native protocol v2 spec is missing column type definition for text
Matt Stump created CASSANDRA-6954: - Summary: Native protocol v2 spec is missing column type definition for text Key: CASSANDRA-6954 URL: https://issues.apache.org/jira/browse/CASSANDRA-6954 Project: Cassandra Issue Type: Bug Components: Core, Documentation website Reporter: Matt Stump Priority: Trivial Native protocol v2 spec is missing column type definition for text. Should be 0x000A. https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v2.spec#L526 -- This message was sent by Atlassian JIRA (v6.2#6252)
