-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Fix DescribeStatement #2795
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix DescribeStatement #2795
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will the version always be inconsistent for a long time ,and we are in this loop for long time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure - is it a statement or question? I think we can skip this sync if paging is not requested; if paging was requested and there happened what you say, we would never be able to return results as paging would always fail due to concurrent schema changes. On the other hand - I don't know under what circumstances that could happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
long time ago, in our cluster, with poor machine configuration, we some time saw that the cluster schema may be inconsistent, and it take a long time for them to reach a consistent state. Some times it due to the poor disk hung, where the system table just locate. Some time is other reasons.
So what about logging here when the loop is more than some times like 3 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I don't think this is a case - it is not waiting here for the cluster schema to be consistent - it is only the local thing - when the schema gets transformed locally, the transformation is applied in a synchronized block. A single transformation may include multiple items which are applied one by one immediately updating the snapshot. On the other hand, scheme version is updated once after the whole transformation is completed. So, here we are just waiting for that synchronized block to complete and make sure that no other synchronized transformation has started in the meantime. In other words, waiting to make sure the metadata and version pertains to the same schema.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see.
52295df to
378823b
Compare
378823b to
d3bc0f2
Compare
|
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1037/workflows/b371e061-4128-446d-b1a9-1adecf3972e9 |
|
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1037/workflows/7af077c4-d44c-461f-8c8a-750790d49b14 (j11) (rerun succeeded https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1037/workflows/7af077c4-d44c-461f-8c8a-750790d49b14/jobs/42939/parallel-runs/4?filterBy=ALL ) |
No description provided.