Hi all, I was investigating this issue which I believed initially to be a JDK bug, but it turns out it's caused by WildFly and I'm not really sure what problems it could cause. The symptom is a NullPointerException being thrown in the "Finalizer" Daemon System Thread, while attempting to shut down a ThreadPoolExecutor: Daemon System Thread [Finalizer] (Suspended (exception NullPointerException)) ThreadPoolExecutor.tryTerminate() line: 694 [local variables unavailable] ThreadPoolExecutor.shutdown() line: 1394 ThreadPoolExecutor.finalize() line: 1477 System$2.invokeFinalize(Object) line: 1267 Finalizer.runFinalizer(JavaLangAccess) line: 98 Finalizer.access$100(Finalizer, JavaLangAccess) line: 34 Finalizer$FinalizerThread.run() line: 210 That line 694 contains this line: (runStateOf(c) == SHUTDOWN && ! workQueue.isEmpty())) // NPE: workQueue==null The "workQueue" is final, and proper checks are in place in the constructor won't allow for it to be initialized with null. So I believe this is merely the "finalizer" being triggered for an instance of ThreadPoolExecutor which was not successfully constructed; indeed if I set a breakpoint on the "throw new IllegalArgumentException()" line of the constructor, this trips on a JMS/HornetQ related stack: Thread [ServerService Thread Pool -- 64] (Suspended (breakpoint at line 1307 in ThreadPoolExecutor)) owns: PostOfficeImpl (id=270) owns: HornetQServerImpl (id=271) owns: JMSServerManagerImpl (id=272) owns: JMSService (id=273) ThreadPoolExecutor.<init>(int, int, long, TimeUnit, BlockingQueue<Runnable>, ThreadFactory, RejectedExecutionHandler) line: 1307 ThreadPoolExecutor.<init>(int, int, long, TimeUnit, BlockingQueue<Runnable>) line: 1195 Executors.newFixedThreadPool(int) line: 89 UUIDGenerator.getHardwareAddress() line: 151 UUIDGenerator.getAddressBytes() line: 263 UUIDGenerator.generateStringUUID() line: 206 PostOfficeImpl.addBinding(Binding) line: 481 HornetQServerImpl.loadJournals() line: 1766 HornetQServerImpl.initialisePart2() line: 1593 HornetQServerImpl.access$1400(HornetQServerImpl) line: 178 HornetQServerImpl$SharedStoreLiveActivation.run() line: 2314 HornetQServerImpl.start() line: 435 JMSServerManagerImpl.start() line: 490 JMSService.doStart(StartContext) line: 155 JMSService.access$000(JMSService, StartContext) line: 60 JMSService$1.run() line: 94 Executors$RunnableAdapter<T>.call() line: 511 FutureTask<V>.run() line: 266 ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142 ThreadPoolExecutor$Worker.run() line: 617 JBossThread(Thread).run() line: 745 JBossThread.run() line: 122 This doesn't seem to be a real problem for the finalizer thread as it ignores any RuntimeException, and also not a problem for the Executor so I guess the puzzle is far less exciting than the subject of this email might have made you believe :-) But still it would be nice to avoid constructing an illegal Executor, and I have no idea if this could be a real problem for those UUID Generator services which I see in the stacktrace. In my integration test I was updating versions of libraries and application server to EAP 6.4.0.Alpha, but still using an old "standalone.xml" file. I guess the outdated configuration file might have fooled some validation. Thanks, Sanne _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 26 January 2015 at 10:15, Eduardo Sant´Ana da Silva <eduardo.santanadasilva(a)gmail.com&gt; wrote: > Hello, > > Could you provide more information? > > > What is your OS, JVM, and WFLY versions? OS -> Linux (custom build, pure 64 bit) JVM -> OpenJDK 64-Bit 1.7.0_65 WFLY -> It's actually the preview of EAP 6.4 - as I say below ;-) - 6.4.0.Alpha I suspect the issue is caused by using an outdated configuration file, this is the one I was using: https://github.com/hibernate/hibernate-search/blob/4.4/integrationtest/as... I guess one isn't supposed to use an outdated configuration file? I don't remember when I forked this configuration file, but it was probably before EAP 6.2, to make some changes necessary to the integration tests we run. The Arquillian based tests in that same module should be able to reproduce the issue, although you'd need to make some changes to upgrade dependencies to EAP 6.4 as that branch is using EAP 6.3. Unfortunately EAP 6.4 is not in Maven yet so I can't commit the version changes... but I suspect you'd have the same problem by using this old configuration file in latest WildFly? Thanks, Sanne > > Which configuration file are you using to startup the server? > > Is there any sample app to reproduce your test? > > > Tnanks > Eduardo Sant'Ana da Silva > > > 2015-01-25 20:18 GMT-02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >> >> Hi all, >> I was investigating this issue which I believed initially to be a JDK >> bug, but it turns out it's caused by WildFly and I'm not really sure >> what problems it could cause. >> >> The symptom is a NullPointerException being thrown in the "Finalizer" >> Daemon System Thread, while attempting to shut down a >> ThreadPoolExecutor: >> >> Daemon System Thread [Finalizer] (Suspended (exception >> NullPointerException)) >> ThreadPoolExecutor.tryTerminate() line: 694 [local variables unavailable] >> ThreadPoolExecutor.shutdown() line: 1394 >> ThreadPoolExecutor.finalize() line: 1477 >> System$2.invokeFinalize(Object) line: 1267 >> Finalizer.runFinalizer(JavaLangAccess) line: 98 >> Finalizer.access$100(Finalizer, JavaLangAccess) line: 34 >> Finalizer$FinalizerThread.run() line: 210 >> >> That line 694 contains this line: >> (runStateOf(c) == SHUTDOWN && ! workQueue.isEmpty())) // NPE: >> workQueue==null >> >> The "workQueue" is final, and proper checks are in place in the >> constructor won't allow for it to be initialized with null. >> So I believe this is merely the "finalizer" being triggered for an >> instance of ThreadPoolExecutor which was not successfully constructed; >> indeed if I set a breakpoint on the "throw new >> IllegalArgumentException()" line of the constructor, this trips on a >> JMS/HornetQ related stack: >> >> Thread [ServerService Thread Pool -- 64] (Suspended (breakpoint at >> line 1307 in ThreadPoolExecutor)) >> owns: PostOfficeImpl (id=270) >> owns: HornetQServerImpl (id=271) >> owns: JMSServerManagerImpl (id=272) >> owns: JMSService (id=273) >> ThreadPoolExecutor.<init>(int, int, long, TimeUnit, >> BlockingQueue<Runnable>, ThreadFactory, RejectedExecutionHandler) >> line: 1307 >> ThreadPoolExecutor.<init>(int, int, long, TimeUnit, >> BlockingQueue<Runnable>) line: 1195 >> Executors.newFixedThreadPool(int) line: 89 >> UUIDGenerator.getHardwareAddress() line: 151 >> UUIDGenerator.getAddressBytes() line: 263 >> UUIDGenerator.generateStringUUID() line: 206 >> PostOfficeImpl.addBinding(Binding) line: 481 >> HornetQServerImpl.loadJournals() line: 1766 >> HornetQServerImpl.initialisePart2() line: 1593 >> HornetQServerImpl.access$1400(HornetQServerImpl) line: 178 >> HornetQServerImpl$SharedStoreLiveActivation.run() line: 2314 >> HornetQServerImpl.start() line: 435 >> JMSServerManagerImpl.start() line: 490 >> JMSService.doStart(StartContext) line: 155 >> JMSService.access$000(JMSService, StartContext) line: 60 >> JMSService$1.run() line: 94 >> Executors$RunnableAdapter<T>.call() line: 511 >> FutureTask<V>.run() line: 266 >> ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142 >> ThreadPoolExecutor$Worker.run() line: 617 >> JBossThread(Thread).run() line: 745 >> JBossThread.run() line: 122 >> >> This doesn't seem to be a real problem for the finalizer thread as it >> ignores any RuntimeException, and also not a problem for the Executor >> so I guess the puzzle is far less exciting than the subject of this >> email might have made you believe :-) >> But still it would be nice to avoid constructing an illegal Executor, >> and I have no idea if this could be a real problem for those UUID >> Generator services which I see in the stacktrace. >> >> In my integration test I was updating versions of libraries and >> application server to EAP 6.4.0.Alpha, but still using an old >> "standalone.xml" file. I guess the outdated configuration file might >> have fooled some validation. >> >> Thanks, >> Sanne >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI >