[
https://issues.apache.org/jira/browse/CASSANDRA-21409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-21409:
----------------------------------------
Reviewers: Caleb Rackliffe, Caleb Rackliffe
Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Status: Review In Progress (was: Patch Available)
> Make StartupChecks.withServiceLoaderTests more robust
> -----------------------------------------------------
>
> Key: CASSANDRA-21409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21409
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Legacy/Core
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 6.x, 7.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Finding 1: ServiceConfigurationError is caught around the wrong call
> - Location: src/java/org/apache/cassandra/service/StartupChecks.java,
> withServiceLoaderTests()
> - Confidence: High
> - Flagged by: Boundary+Resources
> - What's wrong: The try-catch for ServiceConfigurationError wraps
> ServiceLoader.load(), but load() is lazy and almost never throws — the error
> is thrown during iteration when each provider is actually instantiated. The
> for (StartupCheck check : loader) loop that follows is entirely unprotected.
> A malformed META-INF/services file or
> any exception in a custom check's no-arg constructor will throw
> ServiceConfigurationError from the loop, propagate uncaught to
> applyStartupChecks(), and be wrapped in a ConfigurationException, causing the
> node to refuse to start with a misleading "Invalid configuration of
> startup_checks" message instead of a clear SPI loading error or
> a graceful skip with a warning. The fix is to move the try-catch (or add a
> second one) to enclose the loop body.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
