[
https://issues.apache.org/jira/browse/CASSANDRA-17071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542085#comment-17542085
]
Andres de la Peña commented on CASSANDRA-17071:
-----------------------------------------------
This patch seems to make \{{KeyspaceMetricsTest.testMetricsCleanupOnDrop}}, as
reported by CASSANDRA-17658. That test verifies that the metrics of a keyspace
are dropped after dropping the keyspace. However, in some runs the metrics are
still there after dropping. The test used to pass right before committing this
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1611/workflows/e2fe5f89-2ec9-4897-8f9a-07f467a874be]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1611/workflows/59e81b6c-4506-400e-8370-77125536c87a])
and it started to be flaky right after
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1610/workflows/9ba746fc-574b-4e81-8f9a-0af278b9277d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1610/workflows/2eb057c6-ef97-4682-a32c-d1fa1bc2cb2d]).
> Relax schema synchronization when opening a keyspace
> ----------------------------------------------------
>
> Key: CASSANDRA-17071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17071
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 4.1
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> In short, there are two purposes of this change:
> # Move the code around to the more appropriate places (for example, CFS
> specific code for dropping table was moved from SM class to CFS class)
> # Relax the synchronization when adding/removing keyspace instances in SM -
> instead of synchronizing the whole collection of keyspace instances, we only
> synchronize the related item (the original idea authored by [~blambov]).
> The current implementation works because a certain order of opening keyspaces
> is assumed. If a keyspace is already initialized, it is just returned without
> sync and sync is done only to initialize the keyspace. When synchronization
> is extended to the whole method, the system finds itself in a deadlock. This
> means that some keyspace is tried to be opened during initiazation. Currently
> it works fine because the keyspace which is not initialized yet is never
> tried to be opened asynchronously while initializing some other keyspace in a
> different thread. Hence the conclusion about fragility of the current
> solution.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
