Hi We have some work to do for JDK25 (Scheduler, SecurityManager, dependencies check, ..).
I think it's reasonable to target 6.3.0 for JDK25 (including VirtualThread tech preview, CI updates, etc). I will create the tickets and start to work on this with other contributors. Regards JB On Thu, Nov 13, 2025 at 2:08 PM Christopher Shannon <[email protected]> wrote: > > Hi Jon, > > JDK 25 is something I haven't tried out yet (I'm not sure if others have) > so if you can dig into the issue more that would be welcome. There are > going to be more things to fix as well to make ActiveMQ compatible with JDK > 25 as well so it's something that just needs to be worked on in general now > that JDK 25 is released. > > JB and/or Matt, do you guys have any thoughts on which version we > should target JDK 25 compatibility with for ActiveMQ? It might depend how > much needs to be fixed, Artemis just went through some of this recently: > https://issues.apache.org/jira/browse/ARTEMIS-5711 > > Chris > > On Thu, Nov 13, 2025 at 6:19 AM Jonathan Gallimore < > [email protected]> wrote: > > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
