You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "David Capwell (Jira)" <ji...@apache.org> on 2021/11/10 17:19:00 UTC
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor
does not propagate client warnings
[ https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17441853#comment-17441853 ]
David Capwell commented on CASSANDRA-17072:
-------------------------------------------
Can you also work on a trunk patch? Executors were completely rewritten
> 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.1, 4.0.x
>
> Time Spent: 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org