aratno commented on code in PR #1635:
URL:
https://github.com/apache/cassandra-java-driver/pull/1635#discussion_r1524601669
##########
core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/UdtCodec.java:
##########
@@ -105,10 +105,7 @@ public UdtValue decode(@Nullable ByteBuffer bytes,
@NonNull ProtocolVersion prot
int i = 0;
while (input.hasRemaining()) {
if (i == cqlType.getFieldTypes().size()) {
- throw new IllegalArgumentException(
- String.format(
- "Too many fields in encoded UDT value, expected %d",
- cqlType.getFieldTypes().size()));
+ break;
Review Comment:
Thought about this some more. The driver seeing extra fields in a UDT is
expected for a short period after a schema change to add fields, since the
control connection may find out later than the coordinator or replicas, and
EVENTs are sent over the control connection async. It may be worth a warning if
this state persists for too long, since that's an indication that a schema
change EVENT wasn't delivered, but delivery failures are expected to be
tolerated as well.
I think it makes sense to drop this to a DEBUG or TRACE log, rather than
using a no-spam logger.
In the more general case of EVENT delivery failing and client metadata going
out of sync, there's more we could do to retry EVENTs or support bounded
metadata lag, but all of that is out of scope for this ticket.
The only other change I'm considering is whether we should add a hint to
refresh client metadata in this situation where the server has indicated that
it has a new schema the client isn't yet aware of. Metadata refreshes should be
debounced so we don't attempt a refresh on every response decode. Refreshing
client metadata would only help in the case when the control instance does know
about the schema but EVENT delivery failed, not in cases where the control
instance has not yet found out about the new schema but a particular
coordinator has, which is more likely the case for larger clusters.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
