[
https://issues.apache.org/jira/browse/CASSANDRA-11198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156677#comment-15156677
]
Gábor Auth edited comment on CASSANDRA-11198 at 2/22/16 9:35 AM:
-----------------------------------------------------------------
The whole row contains more fields:
{code}
> SELECT * FROM unit_by_transport WHERE
> transportid=24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 and
> id=99c05a70-d686-11e5-a169-97287061d5d1;
transportid | id |
automatic | cityid | cityname | fogradius | gotoxy | healthpoint | incityid |
incityname | lastupdate | level | mxy | nextmove |
nextscheduled | playerid | playername | state | type | veteran | x | y
--------------------------------------+--------------------------------------+-----------+--------+----------+-----------+--------+-------------+----------+------------+------------+-------+---------------+--------------------------+---------------+----------+------------+-------+------+---------+----+----
24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 | 99c05a70-d686-11e5-a169-97287061d5d1 |
null | null | null | null | null | null | null |
null | null | null | {"x":1,"y":2} | 2016-02-19 10:07:06+0000 |
null | null | null | null | null | null | 16 | 34
(1 rows)
{code}
The filled mxy, nextMove, x and y field is suspicious because I have a DAO to
update this fields:
{code}
UPDATE unit SET nextMove=?, x=?, mxy=?, y=? WHERE id=?
{code}
The proper row usually looks like this:
{code}
24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 | 9bdafd10-d686-11e5-a169-97287061d5d1 |
False | 79c7e870-d620-11e5-9d3c-8fc3ad6906e2 | null | 2 | null
| 100 | 79c7e870-d620-11e5-9d3c-8fc3ad6906e2 | Keremali | 2016-02-22
08:47:54+0000 | 0 | {"x":1,"y":4} | 2016-02-18 17:28:53+0000 | 2016-02-22
09:42:12+0000 | 96d89a10-d3e4-11e5-a2f5-9b4ae8310373 | Gargonot | loaded |
SETTLERS | 0 | 19 | 64
{code}
But I cannot understand the root cause of this inconsistency... :(
was (Author: gabor.auth):
The whole row contains more fields:
{code}
> SELECT * FROM unit_by_transport WHERE
> transportid=24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 and
> id=99c05a70-d686-11e5-a169-97287061d5d1;
transportid | id |
automatic | cityid | cityname | fogradius | gotoxy | healthpoint | incityid |
incityname | lastupdate | level | mxy | nextmove |
nextscheduled | playerid | playername | state | type | veteran | x | y
--------------------------------------+--------------------------------------+-----------+--------+----------+-----------+--------+-------------+----------+------------+------------+-------+---------------+--------------------------+---------------+----------+------------+-------+------+---------+----+----
24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 | 99c05a70-d686-11e5-a169-97287061d5d1 |
null | null | null | null | null | null | null |
null | null | null | {"x":1,"y":2} | 2016-02-19 10:07:06+0000 |
null | null | null | null | null | null | 16 | 34
(1 rows)
{code}
The filled mxy, nextMove, x and y field is suspicious because I have a DAO to
update this fields:
{code}
UPDATE unit SET nextMove=?, x=?, mxy=?, y=? WHERE id=?
{code}
The row usually looks like this:
{code}
24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 | 9bdafd10-d686-11e5-a169-97287061d5d1 |
False | 79c7e870-d620-11e5-9d3c-8fc3ad6906e2 | null | 2 | null
| 100 | 79c7e870-d620-11e5-9d3c-8fc3ad6906e2 | Keremali | 2016-02-22
08:47:54+0000 | 0 | {"x":1,"y":4} | 2016-02-18 17:28:53+0000 | 2016-02-22
09:42:12+0000 | 96d89a10-d3e4-11e5-a2f5-9b4ae8310373 | Gargonot | loaded |
SETTLERS | 0 | 19 | 64
{code}
But I cannot understand the root cause of this inconsistency... :(
> Materialized view inconsistency
> -------------------------------
>
> Key: CASSANDRA-11198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11198
> Project: Cassandra
> Issue Type: Bug
> Reporter: Gábor Auth
> Assignee: Carl Yeksigian
> Attachments: CASSANDRA-11198.trace
>
>
> Here is a materialized view:
> {code}
> > DESCRIBE MATERIALIZED VIEW unit_by_transport ;
> CREATE MATERIALIZED VIEW unit_by_transport AS
> SELECT *
> FROM unit
> WHERE transportid IS NOT NULL AND type IS NOT NULL
> PRIMARY KEY (transportid, id)
> WITH CLUSTERING ORDER BY (id ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> I cannot reproduce this but sometimes and somehow happened the same issue
> (https://issues.apache.org/jira/browse/CASSANDRA-10910):
> {code}
> > SELECT transportid, id, type FROM unit_by_transport WHERE
> > transportid=24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 and
> > id=99c05a70-d686-11e5-a169-97287061d5d1;
> transportid | id
> | type
> --------------------------------------+--------------------------------------+------
> 24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 | 99c05a70-d686-11e5-a169-97287061d5d1
> | null
> (1 rows)
> > SELECT transportid, id, type FROM unit WHERE
> > id=99c05a70-d686-11e5-a169-97287061d5d1;
> transportid | id | type
> -------------+----+------
> (0 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
