Hi,

I'm currently building ActiveMQ using Java 25, and running into some
problems where running tests will just 'lock up'. An example
is JmsSchedulerTest. These two threads are both blocked:

"main" #3 [5635] prio=5 os_prio=31 cpu=657.39ms elapsed=1429.54s
tid=0x000000013401ee00 nid=5635 waiting on condition  [0x000000016bacd000]
   java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@25/Native Method)
- parking to wait for  <0x00000007e0cdd530> (a
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(java.base@25
/LockSupport.java:223)
at
java.util.concurrent.locks.AbstractQueuedLongSynchronizer.acquire(java.base@25
/AbstractQueuedLongSynchronizer.java:410)
at
java.util.concurrent.locks.AbstractQueuedLongSynchronizer.acquire(java.base@25
/AbstractQueuedLongSynchronizer.java:650)
at
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(java.base@25
/ReentrantReadWriteLock.java:966)
at
org.apache.activemq.store.kahadb.scheduler.JobSchedulerStoreImpl.unload(JobSchedulerStoreImpl.java:214)
at
org.apache.activemq.store.kahadb.AbstractKahaDBStore.doStop(AbstractKahaDBStore.java:141)
at org.apache.activemq.util.ServiceSupport.stop(ServiceSupport.java:71)
at
org.apache.activemq.broker.scheduler.SchedulerBroker.stop(SchedulerBroker.java:223)
at org.apache.activemq.broker.BrokerFilter.stop(BrokerFilter.java:194)
at
org.apache.activemq.broker.TransactionBroker.stop(TransactionBroker.java:209)
at org.apache.activemq.broker.BrokerService$3.stop(BrokerService.java:2363)
at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:41)
at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:849)
at
org.apache.activemq.broker.scheduler.JobSchedulerTestSupport.tearDown(JobSchedulerTestSupport.java:69)
at
java.lang.invoke.LambdaForm$DMH/0x000001ff01108000.invokeVirtual(java.base@25
/LambdaForm$DMH)
at java.lang.invoke.LambdaForm$MH/0x000001ff01108800.invoke(java.base@25
/LambdaForm$MH)
at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base@25
/Invokers$Holder)
at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base@25
/DirectMethodHandleAccessor.java:154)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base@25
/DirectMethodHandleAccessor.java:104)
at java.lang.reflect.Method.invoke(java.base@25/Method.java:565)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)

"JobScheduler:JMS" #129 [42779] daemon prio=5 os_prio=31 cpu=10.67ms
elapsed=1417.10s tid=0x000000013200c000 nid=42779 waiting on condition
 [0x0000000328c42000]
   java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@25/Native Method)
- parking to wait for  <0x00000007e0cdd530> (a
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(java.base@25
/LockSupport.java:223)
at
java.util.concurrent.locks.AbstractQueuedLongSynchronizer.acquire(java.base@25
/AbstractQueuedLongSynchronizer.java:410)
at
java.util.concurrent.locks.AbstractQueuedLongSynchronizer.acquire(java.base@25
/AbstractQueuedLongSynchronizer.java:650)
at
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(java.base@25
/ReentrantReadWriteLock.java:966)
at
org.apache.activemq.store.kahadb.scheduler.JobSchedulerStoreImpl$8.visit(JobSchedulerStoreImpl.java:696)
at
org.apache.activemq.store.kahadb.data.KahaAddScheduledJobCommand.visit(KahaAddScheduledJobCommand.java:283)
at
org.apache.activemq.store.kahadb.scheduler.JobSchedulerStoreImpl.process(JobSchedulerStoreImpl.java:691)
at
org.apache.activemq.store.kahadb.AbstractKahaDBStore.store(AbstractKahaDBStore.java:495)
at
org.apache.activemq.store.kahadb.AbstractKahaDBStore.store(AbstractKahaDBStore.java:403)
at
org.apache.activemq.store.kahadb.scheduler.JobSchedulerImpl.doSchedule(JobSchedulerImpl.java:252)
at
org.apache.activemq.store.kahadb.scheduler.JobSchedulerImpl.schedule(JobSchedulerImpl.java:100)
at
org.apache.activemq.store.kahadb.scheduler.JobSchedulerImpl.mainLoop(JobSchedulerImpl.java:782)
at
org.apache.activemq.store.kahadb.scheduler.JobSchedulerImpl.run(JobSchedulerImpl.java:699)
at java.lang.Thread.runWith(java.base@25/Thread.java:1487)
at java.lang.Thread.run(java.base@25/Thread.java:1474)

Looking at the ReentrantReadWriteLock$NonfairSync in question in a heap
dump, the 'firstReader' is the JobScheduler:JMS thread, which I assume has
a read lock on this already and both threads are attempting to acquire a
write lock.

Weirdly, I don't see this with Java 21. I'll try and dig in to get some
more information on what's happening, and if appropriate, send a patch.

Any thoughts are welcome - and if no-one has any thoughts, that's cool too,
I'm happy to continue working through this and report back.

Jon

Reply via email to