Cassandra: unconfigured table

Question

TLDR; A table is still inaccessible while system_schema.tables already contains a record respective the table

I'm trying to use Cassandra concurrently. Cassandra version: [cqlsh 5.0.1 | Cassandra 3.11.3 | CQL spec 3.4.4 | Native protocol v4]

I have two Python scripts using cassandra-driver==3.16.0 for Consumer and Producer running in different processes.

While Producer creates and fills table, Consumer waits until table is created with Python script running CQL statement:

table_exists = False
while not table_exists:
    cql = SimpleStatement(
        "SELECT table_name FROM system_schema.tables WHERE keyspace_name = 'test_keyspace' AND table_name = 'test_table'"
    )
    results = cassandra_session.execute(cql)
    table_exists = bool(results.current_rows)

After the statement results with at least one record I make a conclusion that table has been created and try to read it with SELECT:

SELECT * FROM test_keyspace.test_table WHERE ...

But sometimes, I get really annoying error:

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/stress.py", line 128, in runner
    for r in select(TEST_KEYSPACE, table_name):
  File "/stress.py", line 63, in select
    results = cassandra_session.execute(statement)
  File "cassandra/cluster.py", line 2171, in cassandra.cluster.Session.execute
  File "cassandra/cluster.py", line 4062, in cassandra.cluster.ResponseFuture.result
cassandra.InvalidRequest: Error from server: code=2200 [Invalid query] message="unconfigured table test_table"

According to the information I discovered that error happens when SELECT statement executes with a table that has not been created yet. So while system_schema.tables already contains a record about the table, the table is not yet accessible.

Maybe there is a more reliable way to check table accessibility? Or common workaround?

Answer 1

With single node Cassandra setups, I have witnessed structural changes not to propagate immediately. I.e. creating a table, then inserting into it, and the insert fails because the table does not exist. Then you check if the table exists, and it is there. And then, since some time has passed, inserts work.

The only way I managed to make Single Node Cassandras behave consistently is to introduce a one-second-wait after every structural change. This was fine by me, since Single Node Cassandras are only used in local development scenarios. In productive environments, I simply disable the wait.