lizhimins opened a new pull request, #6736:
URL: https://github.com/apache/rocketmq-dashboard/pull/6736
## Why
`ResourceOwnershipGuardTest.migrationConcurrentStartupIsIdempotentTest`
fails roughly **one run in
three** on `rocketmq-studio`:
```
JdbcSQLNonTransientException: General error:
"java.util.ConcurrentModificationException"
at
org.h2.jdbc.meta.DatabaseMetaLocal.getIndexInfo(DatabaseMetaLocal.java:1229)
at
org.h2.jdbc.JdbcDatabaseMetaData.getIndexInfo(JdbcDatabaseMetaData.java:261)
at
...instance.ResourceOwnershipSchemaMigration.indexes(ResourceOwnershipSchemaMigration.java:140)
at ...instance.ResourceOwnershipSchemaMigration.ensureIndex(...:132)
at ...instance.ResourceOwnershipSchemaMigration.afterPropertiesSet(...:99)
```
The file is untouched by recent merges (blob-identical to `8bbe7947a`), so
this is a long-standing
flake rather than a regression — but it makes `mvn test` unreliable as a
merge gate.
## Root cause
H2 answers `getIndexInfo` from a mutable metadata cache without taking a
snapshot. When a second
node starts concurrently and commits a `CREATE INDEX`, the `ArrayList` being
iterated by the first
node's metadata read is structurally modified, and H2 wraps the resulting
`ConcurrentModificationException` in a `SQLException`.
## What this does
Retries the metadata read a bounded number of times
(`INDEX_METADATA_ATTEMPTS = 5`) **only** when the
cause chain carries a `ConcurrentModificationException`; every other
`SQLException` is rethrown
unchanged, so a real failure — including the duplicate-data case
`ensureIndex` deliberately
distinguishes — still surfaces.
**Deliberately not a lock.** Serializing the migration inside one JVM (the
approach in the open
#6175) would make this test assert nothing: it starts migrations
concurrently precisely to prove
idempotency under a race. The production database is MySQL, whose metadata
reads are taken from
committed state and never hit this path.
## Verification
- `ResourceOwnershipGuardTest` run **eight times consecutively: 8 green / 0
red** (one in three
failed before this change)
- Full `mvn -B -ntp test` on the server module: recorded in a follow-up
comment
- The retry is keyed on the exception cause, not on a broad `SQLException`
catch, so the
"failures caused by duplicate data must not be swallowed" contract in
`ensureIndex` is unchanged
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
