Skip to content
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

IGNITE-19227 Wait for schema availability outside JRaft threads #2450

Merged
merged 40 commits into from
Aug 29, 2023

Conversation

rpuch
Copy link
Contributor

@rpuch rpuch commented Aug 15, 2023

https://issues.apache.org/jira/browse/IGNITE-19227

Thank you for submitting the pull request.

To streamline the review process of the patch and ensure better code quality
we ask both an author and a reviewer to verify the following:

The Review Checklist

  • Formal criteria: TC status, codestyle, mandatory documentation. Also make sure to complete the following:
    - There is a single JIRA ticket related to the pull request.
    - The web-link to the pull request is attached to the JIRA ticket.
    - The JIRA ticket has the Patch Available state.
    - The description of the JIRA ticket explains WHAT was made, WHY and HOW.
    - The pull request title is treated as the final commit message. The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
  • Design: new code conforms with the design principles of the components it is added to.
  • Patch quality: patch cannot be split into smaller pieces, its size must be reasonable.
  • Code quality: code is clean and readable, necessary developer documentation is added if needed.
  • Tests code quality: test set covers positive/negative scenarios, happy/edge cases. Tests are effective in terms of execution time and resources.

Notes

@rpuch rpuch force-pushed the ignite-19227 branch 2 times, most recently from e7595d9 to 25ccaf4 Compare August 17, 2023 07:54
@rpuch rpuch changed the title IGNITE-19227 Wait for schema awailability out of JRaft threads IGNITE-19227 Wait for schema availability out of JRaft threads Aug 18, 2023
@rpuch rpuch changed the title IGNITE-19227 Wait for schema availability out of JRaft threads IGNITE-19227 Wait for schema availability outside JRaft threads Aug 21, 2023

String delayDurationPath = "schemaSync.delayDuration";
configDocument = applyTestDefault(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no way to override this value, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish we would be able to get configuration from annotations, but that's for the future

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's marked @Immutable in the configuration, so there should not be any way to override it yet

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, what if subclass wants to have its own value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If someone wants to run a cluster with a different value of some cluster-wide config property, they would use TestIgnitionManager#init() passing the config they need. The code we are looking at now is about DEFAULT values used if no explicit value was supplied when initializing the cluster.

finishTxCmdBldr.commitTimestampLong(commitTimestamp.longValue());
}
return catalogVersionFor(currentTimestamp)
.thenApply(catalogVersion -> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good comment from Vanya, of the same opinion.

finishTxCmdBldr.commitTimestampLong(commitTimestamp.longValue());
}
return catalogVersionFor(currentTimestamp)
.thenApply(catalogVersion -> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wait

catalogManager = new CatalogManagerImpl(
new UpdateLogImpl(metaStorageMgr),
clockWaiter,
() -> schemaSyncConfig.delayDuration().value()
delayDurationMsSupplier
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not pass a constant instead of closure ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because at the moment the constructor is called the node is not started yet, and the configuration becomes available only after we start the node


if (requiredCatalogVersion != NO_VERSION_REQUIREMENT && !isMetadataAvailableFor(requiredCatalogVersion)) {
LOG.warn("Metadata not yet available, group {}, required level {}.", request.groupId(), requiredCatalogVersion);
return RaftRpcFactory.DEFAULT //
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to keep an eye on a number of rejected messages, some new stat field would be great. Can be done as a separate ticket.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I filed a ticket https://issues.apache.org/jira/browse/IGNITE-20298 and added a TODO mentioning this ticket

@@ -42,6 +43,9 @@ public class RaftGroupOptions {
/** Configuration of own striped disruptor for FSMCaller service of raft node, {@code null} means use shared disruptor. */
private @Nullable RaftNodeDisruptorConfiguration ownFsmCallerExecutorDisruptorConfig;

/** Marshaller to marshall/unmarshall commands. */
private @Nullable Marshaller commandsMarshaller;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to override marshaller ? For test purposes ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For partitions, we need to quickly extract requiredCatalogVersion from command's serialized representation without parsing the whole command. To do so, I tweaked the marshaller used for partitions, but it adds one byte to each command that does not have that requiredCatalogVersion. If we use same marshaller for other (non-partition) groups, we unnecessarily increase their (serialized) sizes as well. Hence the necessity to have ability to supply a different marshaller.

@tkalkirill tkalkirill merged commit acded3f into apache:main Aug 29, 2023
@tkalkirill tkalkirill deleted the ignite-19227 branch August 29, 2023 08:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants