cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joshua McKenzie (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9465) No client warning on tombstone threshold
Date Wed, 18 Nov 2015 19:46:11 GMT


Joshua McKenzie commented on CASSANDRA-9465:

First off - sorry for the delay on review.

* Update comment on DebuggableThreadPoolExecutor.LocalSessionWrapper
* I'm concerned about null check in ExecutorLocals:
if (traceState == null && clientWarnState == null)
    return null;
    return new ExecutorLocals(traceState, clientWarnState);
That's propagated into the thread local w/ExecutorLocals.set, so we're expecting all users
of the ExecutorLocals to always check for null before accessing either of these? While I see
us doing that with TraceState, I don't see the same for ClientWarn.State. If the relationship
is "Both are set or both are null", the code in ExecutorLocals.create should reflect that

Also: I could be missing something here so feel free to clue me in; assigning and passing
around ThreadLocal state between threads in an executor service isn't the clearest thing I've
ever reviewed.

> No client warning on tombstone threshold
> ----------------------------------------
>                 Key: CASSANDRA-9465
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Adam Holmberg
>            Assignee: Carl Yeksigian
>            Priority: Minor
>             Fix For: 2.2.x
> It appears that a client warning is not coming back for the tombstone threshold case.
The batch warning works.
> Repro:
> Create a data condition with tombstone_warn_threshold < tombstones < tombstone_failure_threshold
> Query the row
> Expected:
> Warning in server log, warning returned to client
> I'm basing this expectation on what I see [here|]
> Observed:
> Warning in server log, no warning flag in response message.

This message was sent by Atlassian JIRA

View raw message