rzo1 opened a new pull request, #218: URL: https://github.com/apache/openjpa/pull/218
The first scheduled run of the new Databases workflow was red on MariaDB 11.8: the criteria package failed in bulk and the connection pool was then exhausted, `TestMultiselect` spending 170s purely on `Timeout waiting for idle object`. Both problems are in the test suite, on master, and independent of each other — **no production code changes here.** Two commits so they can be reviewed apart. **1. Two unrelated `CompUser` hierarchies defaulted to the same table.** `o.a.o.persistence.criteria.CompUser` and `o.a.o.persistence.common.apps.CompUser` both map to `CompUser` with incompatible columns, so whichever package runs second makes `SynchronizeMappings=buildSchema(SchemaAction=drop,add)` rewrite the table on *every* EntityManagerFactory — and `CriteriaTest` builds one per test method. MariaDB's general query log shows 105 `ALTER TABLE CompUser DROP COLUMN` in a single test class. MariaDB keeps dropped columns in the clustered-index record format, so they keep counting towards the 8126-byte row limit until `ERROR 1118 Row size too large`. A pure-SQL replay of those 14 statements fails at cycle 14 on mariadb:11.8 **and** 11.4, while mysql:8.0 survives 25 cycles — which is exactly why the MySQL job was green on the same suite. Fix: an explicit `@Table(name = "CMN_COMPUSER")` on the `common/apps` fixture. The entity name is untouched, so both the jpql tests' JPQL and the criteria tests' expected SQL stay valid. Why it never showed locally: surefire's default `runOrder=filesystem`. On the Linux runner jpql runs before criteria; on macOS the reverse. Measured on mariadb:11.8 in CI order, on a fresh database — the jpql phase is 123 tests and green either way, the criteria phase goes from **540 tests / 133 failures / 183 errors** (513 of them `Row size too large`) to **544 / 0 / 0**. **2. A failure in `setUp` left a connection in the pool for good.** `junit.framework.TestCase.runBare()` calls `setUp()` *outside* its try/finally, so a failure there skips `tearDown()` entirely. `CriteriaTest.setUp()` opens an EntityManager, and subclasses begin a transaction in their own `setUp()`, which makes the store manager retain a JDBC connection; `CriteriaTest.emf` is static and shared by all 24 criteria classes, so each failure leaked one connection out of a pool sized `MaxTotal=10`. About a dozen failures emptied it, and everything downstream then failed with a pool timeout instead of its own problem. `AbstractCriteriaTestCase.runBare()` now runs `setUp()` inside the guarded block and calls `tearDown()` exactly once either way (what JUnit 4 does for `@Before`/`@After`), and `CriteriaTest.tearDown()` is made null- and exception-safe, since an exception out of `em.close()` previously skipped `emf.close()` and leaked the whole pool. Raising `MaxTotal` or the wait timeout w ould only postpone the symptom, so the profiles are left alone. Both new tests fail without their change (verified by reverting each in a throwaway worktree). The MariaDB row-format behaviour is user-facing on its own — an application using `buildSchema(drop,add)` or `mappingtool -action refresh` hits the same rotation — so it is documented in `supported_databases.xml`, with the remedy. Verified: criteria + jpql packages **667/0/0 on both Derby and H2**; on mariadb:11.8 as above. The third item in the ticket, `TestPessimisticLocks` on PostgreSQL, is **not** in this PR. A change for it was written and then dropped: the test passes 6/6 on postgres:11 on repeated runs here, the failure could not be reproduced, and the justification quoted SQL (`... FOR UPDATE`) that does not appear in the captured statements at all. It is order-dependent in principle — the ranged query carries no `ORDER BY`, so `setFirstResult(1)` skips whichever row the server returns first — but that belongs with OPENJPA-3000, which already tracks lock-manager flakes on PostgreSQL and Oracle, and needs a reproduction before a fix. -- 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]
