[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443588#comment-17443588
]
Jacek Lewandowski commented on CASSANDRA-17072:
-----------------------------------------------
The reason for failing unit tests was my mistake that I forgot to uncomment
byteman runner.
For the trunk, there is a question, perhaps to [~benedict] - I noticed that
migration stage is not local aware while it was in 4.0 - is there any
particular reason why it should not be a local aware? I've changed it to local
aware in the PR for this ticket because migration stage is used during
execution of schema statements and thus should propagate both tracing and
client warnings - is it ok?
PR for trunk: https://github.com/apache/cassandra/pull/1320
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---------------------------------------------------------------
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
> ----
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
