[jira] [Created] (CASSANDRA-11805) Row deleted when value updated to null
Jaroslav Kamenik created CASSANDRA-11805:
Summary: Row deleted when value updated to null
Key: CASSANDRA-11805
URL: https://issues.apache.org/jira/browse/CASSANDRA-11805
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: C* 3.5, both single node and cluster
Reporter: Jaroslav Kamenik
Priority: Critical
It seems that the behaviour of the value update to null differs when row is
created by insert or update. When it is inserted the row stays and the value is
null, when updated the row is deleted.
Simple example:
Inserts:
create table aaa (a ascii, b ascii, c ascii, primary key (a,b));
insert into aaa (a,b,c) values ('a','b','c');
insert into aaa (a,b,c) values ('a','c','d');
insert into aaa (a,b,c) values ('a','d','e');
select * from aaa;
a | b | c
---+---+---
a | b | c
a | c | d
a | d | e
update aaa set c = null where a='a' and b='b';
select * from aaa;
a | b | c
---+---+--
a | b | null
a | c |d
a | d |e
Updates:
create table bbb (a ascii, b ascii, c ascii, primary key (a,b));
update bbb set c = 'c' where a='a' and b='b';
update bbb set c = 'd' where a='a' and b='c';
update bbb set c = 'e' where a='a' and b='d';
select * from bbb;
a | b | c
---+---+---
a | b | c
a | c | d
a | d | e
update bbb set c = null where a='a' and b='b';
select * from bbb;
a | b | c
---+---+---
a | c | d
a | d | e
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9054) Break DatabaseDescriptor up into multiple classes.
[
https://issues.apache.org/jira/browse/CASSANDRA-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-9054:
Status: Patch Available (was: In Progress)
Added a couple of unit tests for all offline tools.
These tests check the theads started by the tool invocation and the components
(say, {{Server}}, {{Schema}}, {{Keyspace}}, CLSM) initialized by a tool.
With this patch, referencing {{DatabaseDescriptor}} no longer implicitly starts
up everything.
Most of the patch is "noise" (e.g. to tell a unit test to startup or
refactorings to remove class dependencies). Details about that are in my long
comment above.
> Break DatabaseDescriptor up into multiple classes.
> --
>
> Key: CASSANDRA-9054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9054
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jeremiah Jordan
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> Right now to get at Config stuff you go through DatabaseDescriptor. But when
> you instantiate DatabaseDescriptor it actually opens system tables and such,
> which triggers commit log replays, and other things if the right flags aren't
> set ahead of time. This makes getting at config stuff from tools annoying,
> as you have to be very careful about instantiation orders.
> It would be nice if we could break DatabaseDescriptor up into multiple
> classes, so that getting at config stuff from tools wasn't such a pain.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9669) If sstable flushes complete out of order, on restart we can fail to replay necessary commit log records
[
https://issues.apache.org/jira/browse/CASSANDRA-9669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283492#comment-15283492
]
Branimir Lambov commented on CASSANDRA-9669:
Patch to remove the synchronization from {{truncateBlocking}} here:
|[3.0|https://github.com/blambov/cassandra/tree/9669-fix-sync-3.0]|[utest|http://cassci.datastax.com/job/blambov-9669-fix-sync-3.0-testall/]|[dtest|http://cassci.datastax.com/job/blambov-9669-fix-sync-3.0-dtest/]|
|[trunk|https://github.com/blambov/cassandra/tree/9669-fix-sync-trunk]|[utest|http://cassci.datastax.com/job/blambov-9669-fix-sync-trunk-testall/]|[dtest|http://cassci.datastax.com/job/blambov-9669-fix-sync-trunk-dtest/]|
(3.0 patch applies cleanly upwards)
This is a temporary fix; I will think more seriously about the safety of this
as part of {{PostFlush}} removal (CASSANDRA-8496).
> If sstable flushes complete out of order, on restart we can fail to replay
> necessary commit log records
> ---
>
> Key: CASSANDRA-9669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9669
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benedict
>Assignee: Benedict
>Priority: Critical
> Labels: correctness
> Fix For: 2.2.7, 3.7, 3.0.7
>
>
> While {{postFlushExecutor}} ensures it never expires CL entries out-of-order,
> on restart we simply take the maximum replay position of any sstable on disk,
> and ignore anything prior.
> It is quite possible for there to be two flushes triggered for a given table,
> and for the second to finish first by virtue of containing a much smaller
> quantity of live data (or perhaps the disk is just under less pressure). If
> we crash before the first sstable has been written, then on restart the data
> it would have represented will disappear, since we will not replay the CL
> records.
> This looks to be a bug present since time immemorial, and also seems pretty
> serious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10992) Hanging streaming sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-10992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283451#comment-15283451
]
mlowicki commented on CASSANDRA-10992:
--
Upgrade to 2.1.14 didn't helped. Still even almost 12h after end of repair run
(using Cassandra Reaper) I've active streams (all with progress set to 100%).
{{streaming_socket_timeout_in_ms}} has default value (360).
> Hanging streaming sessions
> --
>
> Key: CASSANDRA-10992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10992
> Project: Cassandra
> Issue Type: Bug
> Environment: C* 2.1.12, Debian Wheezy
>Reporter: mlowicki
>Assignee: Paulo Motta
> Fix For: 2.1.12
>
> Attachments: apache-cassandra-2.1.12-SNAPSHOT.jar
>
>
> I've started recently running repair using [Cassandra
> Reaper|https://github.com/spotify/cassandra-reaper] (built-in {{nodetool
> repair}} doesn't work for me - CASSANDRA-9935). It behaves fine but I've
> noticed hanging streaming sessions:
> {code}
> root@db1:~# date
> Sat Jan 9 16:43:00 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB
> total
> root@db1:~# date
> Sat Jan 9 17:45:42 UTC 2016
> root@db1:~# nt netstats -H | grep total
> Receiving 5 files, 46.59 MB total. Already received 1 files, 11.32 MB
> total
> Sending 7 files, 46.28 MB total. Already sent 7 files, 46.28 MB total
> Receiving 6 files, 64.15 MB total. Already received 1 files, 12.14 MB
> total
> Sending 5 files, 61.15 MB total. Already sent 5 files, 61.15 MB total
> Receiving 4 files, 7.75 MB total. Already received 3 files, 7.58 MB
> total
> Sending 4 files, 4.29 MB total. Already sent 4 files, 4.29 MB total
> Receiving 12 files, 13.79 MB total. Already received 11 files, 7.66
> MB total
> Sending 5 files, 15.32 MB total. Already sent 5 files, 15.32 MB total
> Receiving 8 files, 20.35 MB total. Already received 1 files, 13.63 MB
> total
> Sending 38 files, 125.34 MB total. Already sent 38 files, 125.34 MB
> total
> {code}
> Such sessions are left even when repair job is long time done (confirmed by
> checking Reaper's and Cassandra's logs). {{streaming_socket_timeout_in_ms}}
> in cassandra.yaml is set to default value (360).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
