Bret McGuire created CASSJAVA-133:
-------------------------------------
Summary: Consider whether we need a mechanism to indicate whether
metadata loaded successfully
Key: CASSJAVA-133
URL: https://issues.apache.org/jira/browse/CASSJAVA-133
Project: Apache Cassandra Java driver
Issue Type: Improvement
Components: Core
Reporter: Bret McGuire
While working on the Data API we recently came across a situation in which
schema queries from the Java driver could fail. The situation is quite
unlikely (and relies on the behaviour of intermediaries between the Java driver
running in the Data API and the corresponding coordinators) but as we see an
increase in Cassandra implementations (and intermediaries) this configuration
is becoming less uncommon.
The Java driver is perfectly fine running without metadata (as provided by
these schema queries). In fact [the current
impl|https://github.com/apache/cassandra-java-driver/blob/4.19.3/core/src/main/java/com/datastax/oss/driver/internal/core/session/DefaultSession.java#L453-L470]
will log such an error but not take any additional corrective action (or
return a different value to the user)... in this case we'll [continue on to
building connection
pools|https://github.com/apache/cassandra-java-driver/blob/4.19.3/core/src/main/java/com/datastax/oss/driver/internal/core/session/DefaultSession.java#L392-L411]
and then return to the user.
We also have no mechanism to determine programmatically if metadata was
successfully loaded. As mentioned above no error code is returned to the user
coming out of DefaultSession.init(). We also have no predicate functions on
DefaultMetadata which indicate whether data was loaded or not. There are
predicates to indicate whether such information _should_ be loaded (either via
programmatic args or the HOCON config) but that's a different proposition.
This ticket isn't intended to propose any kind of implementation yet. The
situation we saw required a number of interacting actors to achieve this result
and none of those were doing anything wrong within their given area; we only
saw the error as a cumulative effect of all these actors working together.
There may be nothing we can do to fix this issue; I'm creating this more as a
platform for discussion than anything else.
A related point: there is no specification for the system tables associated
with Cassandra or the schema queries executed by the driver. None of this is
spelled out in the native protocol docs... it's all basically convention. We
might want to consider that point as well but this is (arguably) external to
the point under consideration.
An additional related point: any change in behaviour coming out of this ticket
should probably be implemented across all the drivers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
