[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445777#comment-17445777
]
Jacek Lewandowski commented on CASSANDRA-17072:
-----------------------------------------------
||PR||j8||j11||
|[4.0|https://github.com/apache/cassandra/pull/1314]|[4.0|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/133/workflows/92089846-2367-44c3-979e-6935b16492ad]|[4.0|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/133/workflows/8a22f82e-b232-43a8-adaf-06ce6e8114ae]
|[trunk|https://github.com/apache/cassandra/pull/1320]|[trunk|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/134/workflows/8a044775-3f00-4aaf-9eab-e6ab6b752bbf]|[trunk|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/134/workflows/cf4afedf-11fb-4b87-82d6-e5919433d394]|
> 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
>
> Time Spent: 2.5h
> 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]
