Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
Jena 3.14.0
-
None
Description
We're evaluating moving from TDB1 to TDB2 and are hitting various concurrency/thread-safety issues that apparently didn't exist with TDB1.
Our setting is as follows: one JVM, ~20 independent TDB1/TDB2 instances, highly concurrent workload involving every TDB1/TDB2 instance.
A common issue we're hitting with TDB2 is this NullPointerException in TransactionalComponentLifecycle:
java.lang.NullPointerException at org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.getReadWriteMode(TransactionalComponentLifecycle.java:324) at org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.complete(TransactionalComponentLifecycle.java:143) at org.apache.jena.dboe.transaction.txn.SysTrans.complete(SysTrans.java:47) at org.apache.jena.dboe.transaction.txn.Transaction.lambda$endInternal$16(Transaction.java:220) at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) at org.apache.jena.dboe.transaction.txn.Transaction.endInternal(Transaction.java:220) at org.apache.jena.dboe.transaction.txn.Transaction.end(Transaction.java:209) at org.apache.jena.dboe.transaction.txn.TransactionalBase._end(TransactionalBase.java:262) at org.apache.jena.dboe.transaction.txn.TransactionalBase.abort(TransactionalBase.java:159) at org.apache.jena.dboe.storage.system.DatasetGraphStorage.abort(DatasetGraphStorage.java:63) at org.apache.jena.sparql.core.DatasetGraphWrapper.abort(DatasetGraphWrapper.java:253) at org.apache.jena.sparql.core.DatasetImpl.abort(DatasetImpl.java:158) at TDB2StressTest.randomRead(TDB2StressTest.java:87) at TDB2StressTest.runStressTestWorker(TDB2StressTest.java:64) at TDB2StressTest.lambda$runStressTest$0(TDB2StressTest.java:43) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834)
The attached "test case" manages to reproduce this issue most of the time on my machine (YMMV of course, since the test is based on quite some concurrency voodoo).
The same test is working flawlessly when run against a TDB1 backend.