[ 
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445871#comment-17445871
 ] 

Berenguer Blasi commented on CASSANDRA-17072:
---------------------------------------------

The runs hadn't finished and in fact there's one still running which seems 
stuck in some concurrency limit. The failure it reports looks unrelated to me 
as the rest of the CI. Happy to +1 but I'll let a day go by to let [~adelapena] 
and [~dcapwell] a last pass and I'll merge tomorrow unless sbdy beats me to it.

> 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]

Reply via email to