[jira] [Updated] (CASSANDRA-8522) Getting partial set of columns in a 'select *' query

["Philip Thompson (JIRA)" <ji...@apache.org>]

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

Philip Thompson updated CASSANDRA-8522:
---------------------------------------
    Reproduced In: 2.0.9
    Fix Version/s:     (was: 2.0.9)
                   2.0.12

> Getting partial set of columns in a 'select *' query
> ----------------------------------------------------
>
>                 Key: CASSANDRA-8522
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8522
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Fabiano C. Botelho
>             Fix For: 2.0.12
>
>
> Configuration:
>    3 node cluster, where two nodes are fine and just one sees the issue reported here. It is an in-memory state  on the server that gets cleared with a cassandra restart on the problematic  node.
> Problem:
> Scenario (this is a run through on the problematic node after at least 6 hours the problem had surfaced):
> 1. After schema had been installed, one can do a  'describe table events' and that shows all the columns in the table, see below:
> {code}
> Use HELP for help.
> cqlsh:sd> DESCRIBE TABLE events
> CREATE TABLE events (
>   dayhour text,
>   id text,
>   event_info text,
>   event_series_id text,
>   event_type text,
>   internal_timestamp bigint,
>   is_read boolean,
>   is_user_visible boolean,
>   link text,
>   node_id text,
>   time timestamp,
>   PRIMARY KEY ((dayhour), id)
> ) WITH
>   bloom_filter_fp_chance=0.100000 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.100000 AND
>   gc_grace_seconds=864000 AND
>   index_interval=128 AND
>   read_repair_chance=0.000000 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   default_time_to_live=0 AND
>   speculative_retry='99.0PERCENTILE' AND
>   memtable_flush_period_in_ms=0 AND
>   compaction={'class': 'LeveledCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> CREATE INDEX events_id_idx ON events (id);
> CREATE INDEX events_event_series_id_idx ON events (event_series_id);
> {code}
> 2. run a query selecting all columns on the same table above:
> {code}
> cqlsh:sd> select * from events limit 10;
>  dayhour       | id                                   | event_series_id                      | is_user_visible
> ---------------+--------------------------------------+--------------------------------------+-----------------
>  2014-12-19:12 | 3a70e8f8-0b04-4485-bf8f-c3d4031687ed | 7c129287-2b3d-4342-8f2b-f1eba61267f6 |           False
>  2014-12-19:12 | 49a854fb-0e6c-43e9-830e-6f833689df0b | 1a130faf-d755-4e52-9f93-82a380d86f31 |           False
>  2014-12-19:12 | 6df0b844-d810-423e-8e43-5b3d44213699 | 7c129287-2b3d-4342-8f2b-f1eba61267f6 |           False
>  2014-12-19:12 | 92d55ff9-724a-4bc4-a57f-dfeee09e46a4 | 1a130faf-d755-4e52-9f93-82a380d86f31 |           False
>  2014-12-19:17 | 2e0ea98c-4d5a-4ad2-b386-bc181e2e7cec | a9cf80e9-b8de-4154-9a37-13ed95459a91 |           False
>  2014-12-19:17 | 8837dc3f-abae-45e6-80cb-c3dffd3f08aa | cb0e4867-0f27-47e3-acde-26b105e0fdc9 |           False
>  2014-12-19:17 | b36baa5b-b084-4596-a8a5-d85671952313 | cb0e4867-0f27-47e3-acde-26b105e0fdc9 |           False
>  2014-12-19:17 | f73f9438-cba7-4961-880e-77e134175390 | a9cf80e9-b8de-4154-9a37-13ed95459a91 |           False
>  2014-12-19:16 | 47b47745-c4f6-496b-a976-381a545f7326 | 4bc7979f-2c68-4d65-91a1-e1999a3bbc7a |           False
>  2014-12-19:16 | 5708098f-0c0a-4372-be03-ea7057a3bd44 | 10ac9312-9487-4de9-b706-0d0af18bf9fd |           False
> {code}
> Note that not all columns show up in the result.
> 3. Try a query that refers to at least one of the missing columns in the result above, but off course one that is in the schema.
> {code}
> cqlsh:sd> select dayhour, id, event_info from events
>       ... ;
> Bad Request: Undefined name event_info in selection clause
> {code}
> Note that it failed saying that 'event_info' was not defined.
> This problem goes away with a restart of cassandra in the problematic node. This does not seem to be the java-320 bug where the fix is supposed to be fixed in driver 2.0.2. We are using driver version 2.0.1. Note that this issue surfaces both with the driver as well as with cqlsh, which points to a problem in the cassandra server. Would appreciate some help with a fix or a quick workaround that is not simply restarting the server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)