11:18 p.m.
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