[
https://issues.apache.org/jira/browse/CASSANDRA-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529216#comment-14529216
]
Tyler Hobbs commented on CASSANDRA-8930:
----------------------------------------
Review comments:
* Instead of using a single string for multiple warnings and separating them
with newlines, use a {{\[string list\]}} to accommodate multiple warnings.
* If an individual warning message is over the max length, truncate it and end
the string with {{\[truncated\]}} instead of discarding it.
* The message for exceeding the batch threshold should indicate the threshold
and actual size. Or, just use the message that we're already logging.
* The ProtocolException that's thrown when warnings are used with a protocol
version < 4 mentions tracing instead of warnings
* The tests should ensure that v3 protocol connections don't get warnings
* I don't think using a thread-local ClientWarning is sufficient. For example,
the tombstone overwhelming warning will happen in the read stage on a different
thread (or on a different node entirely). Only supporting coordinator-level
warnings might be okay for v1 of this, but we need to figure out what the plan
is.
> Add a warn notification for clients
> -----------------------------------
>
> Key: CASSANDRA-8930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8930
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Carl Yeksigian
> Assignee: Carl Yeksigian
> Labels: client-impacting, protocolv4
> Fix For: 3.x
>
> Attachments: 8930-trunk.txt
>
>
> Currently, if a query generates a warning, it is going to be logged server
> side. If the person writing the query is not the admin, that warning isn't
> going to have an impact on the query, and we're just going to fill up the
> server logs.
> We should push these warnings back to the client so the driver users can make
> necessary changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
