9:21 a.m.
On 26 January 2015 at 10:15, Eduardo Sant´Ana da Silva
<eduardo.santanadasilva(a)gmail.com> wrote:
Hello,
Could you provide more information?
What is your OS, JVM, and WFLY versions?
OS -> Linux (custom build, pure 64 bit)
JVM -> OpenJDK 64-Bit 1.7.0_65
WFLY -> It's actually the preview of EAP 6.4 - as I say below ;-) - 6.4.0.Alpha
I suspect the issue is caused by using an outdated configuration file,
this is the one I was using:
https://github.com/hibernate/hibernate-search/blob/4.4/integrationtest/as...
I guess one isn't supposed to use an outdated configuration file? I
don't remember when I forked this configuration file, but it was
probably before EAP 6.2, to make some changes necessary to the
integration tests we run.
The Arquillian based tests in that same module should be able to
reproduce the issue, although you'd need to make some changes to
upgrade dependencies to EAP 6.4 as that branch is using EAP 6.3.
Unfortunately EAP 6.4 is not in Maven yet so I can't commit the
version changes... but I suspect you'd have the same problem by using
this old configuration file in latest WildFly?
Thanks,
Sanne
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI