<div dir="ltr">







<p class="">Hello,</p><p class="">Could you provide more information?</p><p class=""><br>What is your OS, JVM, and WFLY versions?<br></p><p class="">Which configuration file are you using to startup the server?</p><p class="">Is there any sample app to reproduce your test?</p><p class=""><br></p><p class="">Tnanks<br>Eduardo Sant&#39;Ana da Silva</p></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-25 20:18 GMT-02:00 Sanne Grinovero <span dir="ltr">&lt;<a href="mailto:sanne@hibernate.org" target="_blank">sanne@hibernate.org</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
I was investigating this issue which I believed initially to be a JDK<br>
bug, but it turns out it&#39;s caused by WildFly and I&#39;m not really sure<br>
what problems it could cause.<br>
<br>
The symptom is a NullPointerException being thrown in the &quot;Finalizer&quot;<br>
Daemon System Thread, while attempting to shut down a<br>
ThreadPoolExecutor:<br>
<br>
Daemon System Thread [Finalizer] (Suspended (exception NullPointerException))<br>
ThreadPoolExecutor.tryTerminate() line: 694 [local variables unavailable]<br>
ThreadPoolExecutor.shutdown() line: 1394<br>
ThreadPoolExecutor.finalize() line: 1477<br>
System$2.invokeFinalize(Object) line: 1267<br>
Finalizer.runFinalizer(JavaLangAccess) line: 98<br>
Finalizer.access$100(Finalizer, JavaLangAccess) line: 34<br>
Finalizer$FinalizerThread.run() line: 210<br>
<br>
That line 694 contains this line:<br>
(runStateOf(c) == SHUTDOWN &amp;&amp; ! workQueue.isEmpty())) // NPE: workQueue==null<br>
<br>
The &quot;workQueue&quot; is final, and proper checks are in place in the<br>
constructor won&#39;t allow for it to be initialized with null.<br>
So I believe this is merely the &quot;finalizer&quot; being triggered for an<br>
instance of ThreadPoolExecutor which was not successfully constructed;<br>
indeed if I set a breakpoint on the &quot;throw new<br>
IllegalArgumentException()&quot; line of the constructor, this trips on a<br>
JMS/HornetQ related stack:<br>
<br>
Thread [ServerService Thread Pool -- 64] (Suspended (breakpoint at<br>
line 1307 in ThreadPoolExecutor))<br>
owns: PostOfficeImpl  (id=270)<br>
owns: HornetQServerImpl  (id=271)<br>
owns: JMSServerManagerImpl  (id=272)<br>
owns: JMSService  (id=273)<br>
ThreadPoolExecutor.&lt;init&gt;(int, int, long, TimeUnit,<br>
BlockingQueue&lt;Runnable&gt;, ThreadFactory, RejectedExecutionHandler)<br>
line: 1307<br>
ThreadPoolExecutor.&lt;init&gt;(int, int, long, TimeUnit,<br>
BlockingQueue&lt;Runnable&gt;) line: 1195<br>
Executors.newFixedThreadPool(int) line: 89<br>
UUIDGenerator.getHardwareAddress() line: 151<br>
UUIDGenerator.getAddressBytes() line: 263<br>
UUIDGenerator.generateStringUUID() line: 206<br>
PostOfficeImpl.addBinding(Binding) line: 481<br>
HornetQServerImpl.loadJournals() line: 1766<br>
HornetQServerImpl.initialisePart2() line: 1593<br>
HornetQServerImpl.access$1400(HornetQServerImpl) line: 178<br>
HornetQServerImpl$SharedStoreLiveActivation.run() line: 2314<br>
HornetQServerImpl.start() line: 435<br>
JMSServerManagerImpl.start() line: 490<br>
JMSService.doStart(StartContext) line: 155<br>
JMSService.access$000(JMSService, StartContext) line: 60<br>
JMSService$1.run() line: 94<br>
Executors$RunnableAdapter&lt;T&gt;.call() line: 511<br>
FutureTask&lt;V&gt;.run() line: 266<br>
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142<br>
ThreadPoolExecutor$Worker.run() line: 617<br>
JBossThread(Thread).run() line: 745<br>
JBossThread.run() line: 122<br>
<br>
This doesn&#39;t seem to be a real problem for the finalizer thread as it<br>
ignores any RuntimeException, and also not a problem for the Executor<br>
so I guess the puzzle is far less exciting than the subject of this<br>
email might have made you believe :-)<br>
But still it would be nice to avoid constructing an illegal Executor,<br>
and I have no idea if this could be a real problem for those UUID<br>
Generator services which I see in the stacktrace.<br>
<br>
In my integration test I was updating versions of libraries and<br>
application server to EAP 6.4.0.Alpha, but still using an old<br>
&quot;standalone.xml&quot; file. I guess the outdated configuration file might<br>
have fooled some validation.<br>
<br>
Thanks,<br>
Sanne<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-family:Arial;font-size:small">________________</span><span style="font-family:Arial;font-size:small">__________</span><br></div><div><div align="left" style="font-family:Arial;font-size:small">Eduardo Sant&#39;Ana da Silva - Dr.</div><div style="font-family:Arial;font-size:small"><font face="Arial">Pesquisador / Consultor de TI<br></font></div><div style="font-family:Arial;font-size:small"><br></div></div></div></div>
</div>