[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17444505#comment-17444505
]
Andres de la Peña commented on CASSANDRA-17072:
-----------------------------------------------
Changes look good to me, I have left a few mostly cosmetic suggestions on the
4.0 PR that also apply to trunk.
Here are some repeated runs for the changed/new tests, just in case:
||Test||CI||
|{{SchemaStatementWarningsTest}}|[4.0|https://app.circleci.com/pipelines/github/adelapena/cassandra/1146/workflows/c66af191-cda2-409d-a466-a9d5514ab9b4]
[trunk|https://app.circleci.com/pipelines/github/adelapena/cassandra/1147/workflows/7f84c1d9-de24-4e6a-9f81-183512b42ed8]|
|{{DebuggableThreadPoolExecutorTest}}|[4.0|https://app.circleci.com/pipelines/github/adelapena/cassandra/1149/workflows/9c582316-2f57-445d-96cf-b22d1ae8eca4]
[trunk|https://app.circleci.com/pipelines/github/adelapena/cassandra/1148/workflows/de9fff30-5f0e-4db2-9a14-4a23cb211126]|
|{{SEPExecutorTest}}|[4.0|https://app.circleci.com/pipelines/github/adelapena/cassandra/1151/workflows/50eca6a3-710a-49e4-a998-60f7287db98b]
[trunk|https://app.circleci.com/pipelines/github/adelapena/cassandra/1150/workflows/fe98bcea-7b2a-4c83-8f83-077be14d80e5]|
> 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]
