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

Jacek Lewandowski commented on CASSANDRA-17072:
-----------------------------------------------

I rebased both PRs and squashed - I'd really appreciate if somebody confirm 
this 
https://github.com/apache/cassandra/pull/1320/files#diff-884063e4549a5202588049240e62b219f7d14f75d4e983416a61815d84674444R173
 changes is ok in trunk - although it seems obvious for me, I might have missed 
something


> 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: 2h 10m
>  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