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
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev