[wildfly-dev] NPE in finalizer of ThreadPoolExecutor
Eduardo Sant´Ana da Silva
eduardo.santanadasilva at gmail.com
Mon Jan 26 05:15:08 EST 2015
Hello,
Could you provide more information?
What is your OS, JVM, and WFLY versions?
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 at hibernate.org>:
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150126/cb3bdfed/attachment.html
More information about the wildfly-dev
mailing list