<div dir="ltr">The outdated configuration files can cause problems during distributions, depending upon what you use.<div>I had similar problems too. Try to merge your changes in the configuration file of the current version that you are using if the problem persists I can try to reproduce it using a similar environment.</div><div>Give it a try and let me know.</div><div><br></div><div>Thanks</div><div>Eduardo Sant'Ana da Silva</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-28 13:21 GMT-02:00 Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@hibernate.org" target="_blank">sanne@hibernate.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26 January 2015 at 10:15, Eduardo Sant´Ana da Silva<br>
<span class=""><<a href="mailto:eduardo.santanadasilva@gmail.com">eduardo.santanadasilva@gmail.com</a>> wrote:<br>
> Hello,<br>
><br>
> Could you provide more information?<br>
><br>
><br>
> What is your OS, JVM, and WFLY versions?<br>
<br>
</span>OS -> Linux (custom build, pure 64 bit)<br>
JVM -> OpenJDK 64-Bit 1.7.0_65<br>
WFLY -> It's actually the preview of EAP 6.4 - as I say below ;-) - 6.4.0.Alpha<br>
<br>
I suspect the issue is caused by using an outdated configuration file,<br>
this is the one I was using:<br>
<a href="https://github.com/hibernate/hibernate-search/blob/4.4/integrationtest/as/src/as7config/standalone/configuration/standalone-securedjms.xml" target="_blank">https://github.com/hibernate/hibernate-search/blob/4.4/integrationtest/as/src/as7config/standalone/configuration/standalone-securedjms.xml</a><br>
<br>
I guess one isn't supposed to use an outdated configuration file? I<br>
don't remember when I forked this configuration file, but it was<br>
probably before EAP 6.2, to make some changes necessary to the<br>
integration tests we run.<br>
<br>
The Arquillian based tests in that same module should be able to<br>
reproduce the issue, although you'd need to make some changes to<br>
upgrade dependencies to EAP 6.4 as that branch is using EAP 6.3.<br>
Unfortunately EAP 6.4 is not in Maven yet so I can't commit the<br>
version changes... but I suspect you'd have the same problem by using<br>
this old configuration file in latest WildFly?<br>
<br>
Thanks,<br>
Sanne<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Which configuration file are you using to startup the server?<br>
><br>
> Is there any sample app to reproduce your test?<br>
><br>
><br>
> Tnanks<br>
> Eduardo Sant'Ana da Silva<br>
><br>
><br>
> 2015-01-25 20:18 GMT-02:00 Sanne Grinovero <<a href="mailto:sanne@hibernate.org">sanne@hibernate.org</a>>:<br>
>><br>
>> Hi all,<br>
>> I was investigating this issue which I believed initially to be a JDK<br>
>> bug, but it turns out it's caused by WildFly and I'm not really sure<br>
>> what problems it could cause.<br>
>><br>
>> The symptom is a NullPointerException being thrown in the "Finalizer"<br>
>> Daemon System Thread, while attempting to shut down a<br>
>> ThreadPoolExecutor:<br>
>><br>
>> Daemon System Thread [Finalizer] (Suspended (exception<br>
>> 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 && ! workQueue.isEmpty())) // NPE:<br>
>> workQueue==null<br>
>><br>
>> The "workQueue" is final, and proper checks are in place in the<br>
>> constructor won't allow for it to be initialized with null.<br>
>> So I believe this is merely the "finalizer" being triggered for an<br>
>> instance of ThreadPoolExecutor which was not successfully constructed;<br>
>> indeed if I set a breakpoint on the "throw new<br>
>> IllegalArgumentException()" 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.<init>(int, int, long, TimeUnit,<br>
>> BlockingQueue<Runnable>, ThreadFactory, RejectedExecutionHandler)<br>
>> line: 1307<br>
>> ThreadPoolExecutor.<init>(int, int, long, TimeUnit,<br>
>> BlockingQueue<Runnable>) 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<T>.call() line: 511<br>
>> FutureTask<V>.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'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>
>> "standalone.xml" 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>
><br>
><br>
><br>
><br>
> --<br>
> __________________________<br>
> Eduardo Sant'Ana da Silva - Dr.<br>
> Pesquisador / Consultor de TI<br>
><br>
</div></div></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'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>