[wildfly-dev] NPE in finalizer of ThreadPoolExecutor

Wed Jan 28 10:55:43 EST 2015

The outdated configuration files can cause problems during distributions,
depending upon what you use.
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.
Give it a try and let me know.

Thanks
Eduardo Sant'Ana da Silva

2015-01-28 13:21 GMT-02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 26 January 2015 at 10:15, Eduardo Sant´Ana da Silva
> <eduardo.santanadasilva at 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/src/as7config/standalone/configuration/standalone-securedjms.xml
>
> 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 at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> >
> > --
> > __________________________
> > Eduardo Sant'Ana da Silva - Dr.
> > Pesquisador / Consultor de TI
> >
>

-- 
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150128/ce69d7d1/attachment.html 